freetype
[Top][All Lists]
Advanced

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

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


From: Juliusz Chroboczek
Subject: Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
Date: 05 Apr 2002 21:23:45 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

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 hope this clarifies matters, and I suggest that we should close this
completely pointless discussion.

                                        Juliusz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]