On Wed, 2008-01-02 at 16:58 +0000, David wrote: > Hi, > > 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@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
