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

[Brian Stell]

Juliusz Chroboczek wrote:
> ...
> 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?
> 
> 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.

It could.

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

A different way to approach the problem could be to ask 3rd 
party code such as FreeType to use macros for the fuctions
XFree86 needs to override and have XFree86 override those
macros. For example FreeType could have:

  /* Allow outside code to override these */
  #ifndef READ
  #  define READ read
  #endif

XFree86 could define READ to be xf86_read and thus override
the values in FreeType. This would follow common C protocol
and allow readers of FreeType to know that these were macros.

This more directly address the issue that XFree86 has whereas 
changing the structure member names hides the issue.

The FreeType code would have clear markings where things were 
being "fiddled with under the hood".

-- 
Brian Stell