Norman Gray <[EMAIL PROTECTED]> writes: > Having __STDC__ equal to 0 violates the standard, thus this test is > giving the wrong result. I've no idea what these `useful extensions' > are, and if I did, I'd certainly be sure to avoid them,
Some of these "useful extensions" are <stdio.h> functions like fileno, which are required by POSIX. Standard-conforming C implementations must disabling these functions, since the C standard says that the following program must work: #include <stdio.h> double fileno; However, as a practical matter, I've found that it's more hassle to disable functions like fileno than it is to enable them. Name clashes like the above are extremely rare in real programs -- they won't survive in traditional environments, and they won't survive in most default platforms, as they all (wisely) have decided not to break existing code. Conversely, a lot of real-world code uses "fileno" without using the POSIX-blessed method for attacking this problem. I think changing Autoconf to break this real-world code would cause more problems than it would cure. That being said, it might be reasonable to define a new Autoconf macro AC_PROG_CC_STDC_PEDANTIC, or something like that, which tests for 100% conformance to the C Standard in matters like this. > There's a current problem: if you process the configure from GNU m4 > 1.4 with autoconf 2.57, and run the resulting ./configure, the > resulting Makefile does not have -std1 in the CFLAGS As far as I can easily tell on my host, that's fixed if one applies Autoconf 2.59 (the current version) to M4 1.4.2 (the current version). My understanding is that Autoconf 2.59 will append -std1, that CVS Autoconf will append -std, and that either will work for M4 1.4.2 on Tru64.
