[Fontconfig] Understanding the FcValue type == FcTypeString

[David]

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.
>
>