[Fontconfig] Understanding the FcValue type == FcTypeString
keithp at keithp.com
Wed Jan 2 09:53:37 PST 2008
On Wed, 2008-01-02 at 16:58 +0000, David wrote:
> I notice that a fc_value_string macro is used to retrieve a string from
> an FcValue object.
> #define FcValueString(v) FcPointerMember(v, u.s, FcChar8)
> Which seems to expand to:
> (((intptr_t) (v->u.s) & 1) != 0) ?
> (FcChar8 *) ((intptr_t) v + ((intptr_t) (v->u.s) & ~1))
> : v->u.s
The commends around the definition of FcValueString, FcValueCharSet and
FcValueLangSet are relevant here -- fontconfig uses offsets instead of
pointers almost everywhere as this allows objects to live in mmap'd
files without requiring them to be mapped at a specific address.
However, the FcValue type is exposed, and so sometimes these three types
may end up as regular pointers instead of offsets. I stole the low bit
of the pointer to disambiguate pointers from offsets, which is an ugly
hack, but I needed to preserve ABI compatiblity and so couldn't change
the FcValue datatype.
> As I understand it, if the string is at an odd address, then return the
> base FcValue object address + the 31 most significant bits of the
> address of the string, otherwise return the address of the string.
Odd pointer values are not addresses, they're offsets. The rest of the
internal data structures use offsets exclusively.
Hmm. I might be able to use a bit of the FcType field instead of the
pointer itself. That might be safer in the presence of systems that can
pass strings with odd addresses to the library.
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20080102/4003e894/attachment.pgp
More information about the Fontconfig