Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On Thu, 22 Mar 2007 11:43:58 +0900, Miles Bader [EMAIL PROTECTED] said: David Turner [EMAIL PROTECTED] writes: this will generate an error with certain compilers/pre-processors if __LP64__ is not defined. generally speaking #if X is not a portable statement, except if you ensure that the macro is always defined beforehand. Is this true according to the C standard, or a problem with any non-obsolete compilers? This is one of these things that are certainly not clarified in the C standard [1], which specifies that #if shall be followed by any constant-expression, the latter being defined very loosely in the C language description, and specific constraints not really detailed. So #if FOO, where FOO is undefined is ok with GNU cpp [2] but not with Visual C++ [3] I haven't looked at other compilers, but I wouldn't be surprised to see that this is a GNU-specific extension, or it may come from a tradition of various Unix pre-processors, but certainly can't be generalized... [I ask because such usage is widespread, and although gcc has a warning for it, it doesn't get turned on even with -ansi -pedantic -Wall -Wextra, you have to enable it explicitly.] I have no idea why, I suppose that forcing -Wundef with -ansi -pedantic would have created problems when compiling a lot of code, due to its widespread usage in Unix sources. Hope this helps, - David [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf [2] http://gcc.gnu.org/onlinedocs/cpp/If.html#If [3] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vcrefPreprocessorReference.asp ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
The relevant part is where it says how to handle incorrect expression syntax in an #if statement. Because where FOO is undefined, #if FOO expands to a null expression which is not a valid one... I have not found anything in the document that discusses this case; maybe I missed it, but it's strange that the MSDN documentation doesn't mention it on the other hand, I just tried to compiled the following program on Windows: #if FOO_IS_UNDEFINED #error should not happen #else int dummy; #endif I had correct compilation, without warnings with all the following compilers though: MingW (GCC) Visual C++ 6 Visual C++ 7 Borland C++ 5.5 OpenWatcom C++ (don't remember version) Win32-LCC (don't remember version) I only used the default compiler options though (no -ansi or equivalent); I would say it's pretty widely supported. Apparently the Microsoft compilers and their documentation don't agree on everything; I'm not too surprised, I've seen the same thing with GCC :-) Regards, - David So #if FOO, where FOO is undefined is ok with GNU cpp [2] but not with Visual C++ [3] I haven't looked at other compilers, but I wouldn't be surprised to see that this is a GNU-specific extension, or it may come from a tradition of various Unix pre-processors, but certainly can't be generalized... Well, a trick I have used in one of my projects is to write #if FOO+0 but most people don't like it. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
On 3/22/07 10:17 AM, [EMAIL PROTECTED] said: Now I'm going to commit your patch to CVS head, but I have small question. Your patch to builds/unix/ftconfig.in will disable Carbon support on 64bit ABI in Intel Mac. It means that the resource-fork based font support (ftmac.c) are unavailable completely. Not only deprecated QuickDraw and FileManager (FSSpec etc) functions, but also ATS and FSRef functions. It is intended design? Yes. On the current Mac OS (10.4.9 and earlier), on both PPC and Intel, none of QuickDraw, File Manager, ATS, FSRefs, FSSpecs, etc. are available to 64 bit applications. Basically, ftmac.c cannot work in 64 bit on 10.4. On 10.5, ftmac.c will be able to work in 64 bit, but since 10.5 is unreleased -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Quoting David Turner [EMAIL PROTECTED]: I haven't looked at other compilers, but I wouldn't be surprised to see that this is a GNU-specific extension, or it may come from a tradition of various Unix pre-processors, but certainly can't be generalized... KR C allowed that syntax. I had thought it was standard C too. I'd say that Visual C isn't following the conventions and that this almost qualifies as a bug in it. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
David Turner [EMAIL PROTECTED] writes: I had correct compilation, without warnings with all the following compilers though: MingW (GCC) Visual C++ 6 Visual C++ 7 Borland C++ 5.5 OpenWatcom C++ (don't remember version) Win32-LCC (don't remember version) I also tried several proprietary compilers at work (including one using the EDG frontend, well known for being highly standard compliant), with the same results -- correct compilation, no warning. I used the most strict warning mode/option I could find with all of them. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
