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 _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts