Re: Understanding the FcValue type == FcTypeString

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.


Attachment: signature.asc
Description: This is a digitally signed message part

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux