I decided to tackle the ANSI C assumption next. If we assume an ANSI C compiler, then a number of checks for header files required by the standard can be deleted. Working from the list here: http://en.wikipedia.org/wiki/ANSI_C_standard_library I started zapping tests. Once finished, I tried building. Everything seemed to work fine except the _locale module wouldn't build because my Mac doesn't have wchar.h. So, is wchar.h part of the ANSI C standard or is Apple's GCC setup (Mac OS X 10.2.8, gcc 3.3) in error? Skip
>> So, is wchar.h part of the ANSI C standard or is Apple's GCC setup >> (Mac OS X 10.2.8, gcc 3.3) in error? Martin> wchar.h is not part of ISO C 89 (and thus not of ANSI C). It was Martin> added to ISO C in Addendum 1 (1994), and is part of ISO C 99. Dang. Okay, I'll add that back in. Is there a more authoritative online source for this stuff than what I stumbled upon? Skip
Skip Montanaro wrote:
Dang. Okay, I'll add that back in. Is there a more authoritative online source for this stuff than what I stumbled upon?
You mean, except for the standard itself, and including historical aspects? http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/newinc9x.htm gives the history. As this is a document of the standards working group, it is pretty accurate. A bit more elaboration is from Clive Feather, who is one of the authors of standard C: http://www.lysator.liu.se/c/na1.html It appears that this site lists a lot of useful material: http://www.lysator.liu.se/c/ Notice that, by ANSI procedures, many ISO standards also become ANSI standards - so C99 is an ANSI standard as well. Therefore, a claim "ANSI C has wchar.h is equally right *and* wrong". Regards, Martin
>> Is there a more authoritative online source for this stuff than what >> I stumbled upon? [ several pointers I need to bookmark elided ] Martin> Notice that, by ANSI procedures, many ISO standards also become Martin> ANSI standards - so C99 is an ANSI standard as well. Therefore, Martin> a claim "ANSI C has wchar.h is equally right *and* wrong". So, I take it Python currently insists on conformance with C89, correct? I'll get it one of these days. Skip
Skip Montanaro wrote:
So, I take it Python currently insists on conformance with C89, correct?
Correct: It is ok if it breaks if the system does not have all C89 features. Lack of some C99 features is ok. (Notice that this is slightly different from "insists on conformance with C89": A C99 implementation is not strictly conforming with C89, e.g. because the value of the __STDC__ macro is different. However, a C99 implementation will support all C89 features). Regards, Martin
participants (2)
-
"Martin v. Löwis"
-
Skip Montanaro