Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86

[Sergey Babkin]

Juliusz Chroboczek wrote:
> 
> Hi Antoine!
> 
> So nice to hear from you.
> 
> BS> Defining common names like ''read'' always leads to problems
> BS> when using multiple packages.
> 
> BS> Why doesn't XFree86 follow common C protocol and use uppercase?
> 
> >> The goal being to use common source code both in the X server (when
> >> using the wrappers) and outside it, it would be rather pointless to
> >> use ``common C protocol'', wouldn't it?
> 
> AL> I am not sure you (both Brian and Juliusz) will have a similar dispute
> AL> about tolower or malloc, would you?
> 
> We're not having a dispute.  A dispute is a form of exchange, and in
> this case Brian is obviously not listening.
> 
> Brian is absolutely right that all-caps names should be used for
> processor defines in the ordinary case, and XFree86 code follows this
> convention religiously.  The definitions done in xf86_ansic.h are in a
> completely different situation, and Brian's received wisdom does not
> apply to them.
> 
> In XFree86 modules that include xf86_ansic.h, a number of libc symbols
> (standard or not, that's not the point) are redirected to their
> cross-platform xf86_* equivalents.  Due to the lack of a module system
> in C, this redirection is done at the preprocessor level:
> 
>   #define read(x, y, z) xf86_read(x, y, z)
>   #define tolower(x) xf86_tolower(x)
>   ... etc ...
> 
> Obviously, the fact that it's the very names used by libc that are
> redefined is the very essence of the hack in question.  Suggesting
> that we redefine some other names instead is missing the point
> althegither.

I guess what Brian is trying to say is that it's much cleaner to do it
the other way around: use xf86_read() etc. throughout the code
and then if you are compiling this code not in the XF86 server
then include a header that would do defines like

#define xf86_read(x, y, z) read(x, y, z)
 
The way it's done now is an extremely dirty hack.

-SB