From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10407 invoked by alias); 11 Oct 2011 11:44:17 -0000 Received: (qmail 10397 invoked by uid 22791); 11 Oct 2011 11:44:16 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from nm30.access.bullet.mail.sp2.yahoo.com (HELO nm30.access.bullet.mail.sp2.yahoo.com) (98.139.44.157) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 11 Oct 2011 11:44:02 +0000 Received: from [98.139.44.97] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 11 Oct 2011 11:44:02 -0000 Received: from [98.139.44.65] by tm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 11 Oct 2011 11:44:02 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 11 Oct 2011 11:44:02 -0000 Received: (qmail 89730 invoked from network); 11 Oct 2011 11:44:01 -0000 X-Yahoo-SMTP: mjD.OBqswBAPbVUxYJaYPvc61jLEnpq8VnBwJGdbEJOPA9xw Received: from [192.168.1.113] (gchicares@75.16.161.215 with plain) by smtp107.sbc.mail.ne1.yahoo.com with SMTP; 11 Oct 2011 04:44:01 -0700 PDT Message-ID: <4E942C00.7090009@sbcglobal.net> Date: Tue, 11 Oct 2011 11:44:00 -0000 From: Greg Chicares User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: stdio.h: broken standard compliance. References: <203df9f173be7f13d23b3e7c0fc831c1@127.0.0.1> In-Reply-To: <203df9f173be7f13d23b3e7c0fc831c1@127.0.0.1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-10/txt/msg00166.txt.bz2 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 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