[Fontconfig] Understanding the FcValue type == FcTypeString
david.welch at thorcom.co.uk
Thu Jan 3 02:16:57 PST 2008
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:
>> 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.
More information about the Fontconfig