[Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
Brian Stell wrote: Defining common names like ''read'' always leads to problems when using multiple packages. Fully agreed. Why doesn't XFree86 follow common C protocol and use uppercase? Perhaps because this is not *that* common, except of course for the C code produced by a small company in far north-west USA, named something like yocto$oft. ;-) Better yet, why not use a name like XF86_READ to avoid conflicts on such common names? This sounds much much better to me. Also an option is XF86_Read (plain full caps is commonly reserved for manifest constants). Antoine ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
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? The symbol name is xf86_read; it is the choice of the module author whether to include xf86_libc and use xf86_read directly, or whether to include xf86_ansic and have a nice define from read to xf86_read. Hmmm, just to point out that read is not ANSI C (it is POSIX instead), and that using read in any ANSI C source always lead to problems, because (obviously) there is a number of platforms where read() is defined, even when compiling for strict ANSI C... I am not sure you (both Brian and Juliusz) will have a similar dispute about tolower or malloc, would you? Antoine ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
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 ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
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? BS Better yet, why not use a name like XF86_READ to avoid conflicts BS on such common names? 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? The symbol name is xf86_read; it is the choice of the module author whether to include xf86_libc and use xf86_read directly, or whether to include xf86_ansic and have a nice define from read to xf86_read. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
My wrong. Sorry for that. WL is in the middle of the ftsystem.c instead of the beginning. For some reason, I was convinced that malloc needs to be defined (by the #include), then undefined, then defined again. I'm glad it's not needed. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
