This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: cygwin 1.5.24-2 gcc 3.4.4 stdio.h
On Nov 30 18:45, Jeff Johnston wrote:
> Corinna Vinschen wrote:
>> If it's generally correct to guard the _POSIX_xxx flags with a
>> !__STRICT_ANSI__, shouldn't this guard surround all definitions
>> instead of only the ones for Cygwin?
>> However, I don't think that it is actually correct because the
>> _POSIX_xxx flags should always be defined to be able to check for OS
>> features. I'm rather curious why the `#ifndef __STRICT_ANSI__', which
>> guards all of sys/signal.h except the signal names, has been commented
>> out once.
>
> It is not "wrong" to not define the flags for C89. They don't exist in the
> C89 spec. Code that "needs" to be compiled C89 ANSI won't be checking
> _POSIX flags and certainly won't be doing so without checking for them
> being defined first. If you feel there is a legitimate usage case, you can
> always add a #else for Cygwin.
Well, I'm not sure. It just occured to me that glibc still defines
these values, regardless of __STRICT_ANSI__. If I had the choice, I'd
rather keep it more along the lines of Linux.
> Yes, the check would be better outside both Cygwin and RTEMS.
>
> Regarding the __STRICT_ANSI__ check in sys/signal.h, it appears to have
> been removed when the RTEMS headers were merged in and I can restore it
> with the more complex check so C++ and C99 are not affected.
Fine with me. I'm mainly interested that everything works in the
normal, !__STRICT_ANSI__ case.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat