Ah, I forgot to mention I am using a memory checker called DUMA. This doesn't happen without DUMA, so it is probably doing something funny with the alignment. Keith Packard wrote: > 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. > > _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
