On 2011-10-10 18:42Z, Kaz Kylheku wrote:
>
> Corinna Vinschen writes:
>
>> > $ gcc -Wall -ansi -D_POSIX_C_SOURCE=2 posix-ansi.c
> ^^^^^
>> fileno and pclose are *not* ANSI functions. Therefore, if you define
>> -ansi, you get the below errors. The newlib headers have explicit
>> #ifndef __STRICT_ANSI__ guards around the non-ANSI definitions.
[...]
> I do not believe that your interpretation of the applicable standards
> is
> entirely correct.
>
> The -ansi flag tells the GNU *compiler* to disable its built-in
> extensions. So for instance the block evaluation syntax
> ({ expr1; ... ; exprn }) won't be available.
It does more than that:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/C-Dialect-Options.html
| The macro __STRICT_ANSI__ is predefined when the -ansi option is used.
| Some header files may notice this macro and refrain from declaring
| certain functions or defining certain macros that the ISO standard
| doesn't call for; this is to avoid interfering with any programs that
| might use these names for other things.
This is a "strictly conforming program" as defined by ISO standard C:
#include <stdio.h>
int fileno(int x) {return 3 * x;}
int main() {return fileno(2);}
With '-ansi', the posix declaration of fileno() is suppressed; if it
weren't, then that program would fail to compile. See:
http://gcc.gnu.org/ml/gcc-help/2004-09/msg00280.html
An argument could be made for giving _POSIX_C_SOURCE precedence over
__STRICT_ANSI__ if both are defined; but as long as that's not the
behavior, you might want to undef __STRICT_ANSI__ as appropriate.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
