__STRICT_ANSI__ and stdio.h

__STRICT_ANSI__ and stdio.h

[KIMURA Masaru]

Hi,

is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
for a specific example, see a cparser issue[1] i submitted.

Peace,
-----
[1] https://github.com/MatzeB/cparser/issues/10

--
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

Re: __STRICT_ANSI__ and stdio.h

[cyg Simple]

On 12/12/2015 2:51 AM, KIMURA Masaru wrote:
> Hi,
> 
> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
> for a specific example, see a cparser issue[1] i submitted.
> 

Cygwin isn't wrong.  __STRICT_ANSI__ doesn't mix with POSIX.
__STRICT_ANSI__ definitions is what you should look at for the defined
API; not POSIX 1003.1:2001.

-- 
cyg Simple

--
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

Re: __STRICT_ANSI__ and stdio.h

[KIMURA Masaru]

Hi,

>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>> for a specific example, see a cparser issue[1] i submitted.
>>
>
> Cygwin isn't wrong.  __STRICT_ANSI__ doesn't mix with POSIX.
> __STRICT_ANSI__ definitions is what you should look at for the defined
> API; not POSIX 1003.1:2001.

then why does glibc look accepting -std=c99 -D_POSIX_C_SOURCE=200809L?
so you mean linux (maybe glibc?) is wrong and cygwin (maybe newlib?) is right?

w/ attached source that uses popen()/pclose() via gcc -std=c99,

on cygwin (maybe newlib?), i got,
p.c: In function ‘main’:
p.c:5:2: warning: implicit declaration of function ‘popen’
[-Wimplicit-function-declaration]
  FILE *pp = popen("cat", "w");
  ^
p.c:5:13: warning: initialization makes pointer from integer without a cast
  FILE *pp = popen("cat", "w");
             ^
p.c:12:3: warning: implicit declaration of function ‘pclose’
[-Wimplicit-function-declaration]
   int err = pclose(pp);
   ^

on linux (maybe glibc?), i got,
p.c: In function 'main':
p.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
 int main(int argc, char *argv[]) {
              ^
p.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
 int main(int argc, char *argv[]) {

                          ^                          ^

Peace,

--
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

Re: __STRICT_ANSI__ and stdio.h

[KIMURA Masaru]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

oops!
forgot to attach p.c, so resending now...

> Hi,
>
>>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
>>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>>> for a specific example, see a cparser issue[1] i submitted.
>>>
>>
>> Cygwin isn't wrong.  __STRICT_ANSI__ doesn't mix with POSIX.
>> __STRICT_ANSI__ definitions is what you should look at for the defined
>> API; not POSIX 1003.1:2001.
>
> then why does glibc look accepting -std=c99 -D_POSIX_C_SOURCE=200809L?
> so you mean linux (maybe glibc?) is wrong and cygwin (maybe newlib?) is right?
>
> w/ attached source that uses popen()/pclose() via gcc -std=c99,
>
> on cygwin (maybe newlib?), i got,
> p.c: In function ‘main’:
> p.c:5:2: warning: implicit declaration of function ‘popen’
> [-Wimplicit-function-declaration]
>   FILE *pp = popen("cat", "w");
>   ^
> p.c:5:13: warning: initialization makes pointer from integer without a cast
>   FILE *pp = popen("cat", "w");
>              ^
> p.c:12:3: warning: implicit declaration of function ‘pclose’
> [-Wimplicit-function-declaration]
>    int err = pclose(pp);
>    ^
>
> on linux (maybe glibc?), i got,
> p.c: In function 'main':
> p.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
>  int main(int argc, char *argv[]) {
>               ^
> p.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
>  int main(int argc, char *argv[]) {
>
>                           ^                          ^
>
> Peace,

[-- Attachment #2: p.c --]
[-- Type: text/x-csrc, Size: 278 bytes --]

#define _POSIX_C_SOURCE 200809L
#include <assert.h>
#include <stdio.h>
int main(int argc, char *argv[]) {
	FILE *pp = popen("cat", "w");
	assert(pp != NULL);
	{
		int n = fprintf(pp, "foo\n");
		assert(n >= 0);
	}
	{
		int err = pclose(pp);
		assert(err != -1);
	}
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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

Re: __STRICT_ANSI__ and stdio.h

[cyg Simple]

On 12/13/2015 11:56 PM, KIMURA Masaru wrote:
> Hi,
> 
>>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
>>> especially, i meant routines in POSIX 1003.1:2001 (popen(), pclose(), etc).
>>> for a specific example, see a cparser issue[1] i submitted.
>>>
>>
>> Cygwin isn't wrong.  __STRICT_ANSI__ doesn't mix with POSIX.
>> __STRICT_ANSI__ definitions is what you should look at for the defined
>> API; not POSIX 1003.1:2001.
> 
> then why does glibc look accepting -std=c99 -D_POSIX_C_SOURCE=200809L?

You'll have to ask glibc why it does this.  That doesn't change the fact
that -std=c99 implies -ansi in gcc.  And you define what ever you like
with -D on the command line; regardless if it is right or wrong.

> so you mean linux (maybe glibc?) is wrong and cygwin (maybe newlib?) is right?

Maybe both are correct and the discrepancy is implementation specific.
Maybe you mean the build of glibc uses the above but glibc is defining
the functions and not just declaring them.  If glibc headers are
declaring popen()/pclose() even if __STRICT_ANSI__ is defined I would
dare to say they are incorrect in implementation.

> 
> w/ attached source that uses popen()/pclose() via gcc -std=c99,
> 

Attaching source code doesn't resolve the fact that popen()/pclose() are
POSIX specific and you've asked for __STRICT_ANSI__ which eliminates the
declarations that are not ANSI specific.

> on cygwin (maybe newlib?), i got,
> p.c: In function ‘main’:
> p.c:5:2: warning: implicit declaration of function ‘popen’
> [-Wimplicit-function-declaration]
>   FILE *pp = popen("cat", "w");
>   ^
> p.c:5:13: warning: initialization makes pointer from integer without a cast
>   FILE *pp = popen("cat", "w");
>              ^
> p.c:12:3: warning: implicit declaration of function ‘pclose’
> [-Wimplicit-function-declaration]
>    int err = pclose(pp);
>    ^
> 
> on linux (maybe glibc?), i got,
> p.c: In function 'main':
> p.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
>  int main(int argc, char *argv[]) {
>               ^
> p.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
>  int main(int argc, char *argv[]) {
> 
>                           ^                          ^

Again, implementation specifics maybe.  Try with -pedantic to see if it
changes the result.

-- 
cyg Simple

--
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

Re: __STRICT_ANSI__ and stdio.h

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Dec 12 16:51, KIMURA Masaru wrote:
> Hi,
> 
> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?

Cygwin is using newlib, newlib is BSD based.  We introduced the
compatibility checking macros from FreeBSD lately.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: __STRICT_ANSI__ and stdio.h

[KIMURA Masaru]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Hi,

>> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
>
> Cygwin is using newlib, newlib is BSD based.  We introduced the
> compatibility checking macros from FreeBSD lately.

i roughly checked FreeBSD include/stdio.h and sys/sys/cdefs.h.
https://github.com/freebsd/freebsd/blob/master/include/stdio.h
https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h

it looks very different to newlib's.
FreeBSD has visibility for popen()/pclose() if __POSIX_VISIBLE >= 199209,
it looks no checking about __STRICT_ANSI__ in their cdefs.h.
only one thing i worried about is _ANSI_SOURCE in their cdefs.h,
(b/c i don't understand where _ANSI_SOURCE comes from...)
but it looks _POSIX_C_SOURCE wins anyway.
for ease to see, i'd attach simplified their cdefs.h for their
visibility handling.

anyway, IIUC, newlib's behavior in regard this point looks not
equivalent to FreeBSD's...

Peace,

[-- Attachment #2: cdefs.h --]
[-- Type: text/x-chdr, Size: 1960 bytes --]

#if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 1
 #undef _POSIX_C_SOURCE
 #define _POSIX_C_SOURCE 199009
#endif

#if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 2
 #undef _POSIX_C_SOURCE
 #define _POSIX_C_SOURCE 199209
#endif

#ifdef _XOPEN_SOURCE
 #if _XOPEN_SOURCE - 0 >= 700
  #define __XSI_VISIBLE 700
  #undef _POSIX_C_SOURCE
  #define _POSIX_C_SOURCE 200809
 #elif _XOPEN_SOURCE - 0 >= 600
  #define __XSI_VISIBLE 600
  #undef _POSIX_C_SOURCE
  #define _POSIX_C_SOURCE 200112
 #elif _XOPEN_SOURCE - 0 >= 500
  #define __XSI_VISIBLE 500
  #undef _POSIX_C_SOURCE
  #define _POSIX_C_SOURCE 199506
 #endif
#endif

#if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE)
 #define _POSIX_C_SOURCE 198808
#endif

#ifdef _POSIX_C_SOURCE
 #if _POSIX_C_SOURCE >= 200809
  #define __POSIX_VISIBLE 200809
  #define __ISO_C_VISIBLE 1999
 #elif _POSIX_C_SOURCE >= 200112
  #define __POSIX_VISIBLE 200112
  #define __ISO_C_VISIBLE 1999
 #elif _POSIX_C_SOURCE >= 199506
  #define __POSIX_VISIBLE 199506
  #define __ISO_C_VISIBLE 1990
 #elif _POSIX_C_SOURCE >= 199309
  #define __POSIX_VISIBLE 199309
  #define __ISO_C_VISIBLE 1990
 #elif _POSIX_C_SOURCE >= 199209
  #define __POSIX_VISIBLE 199209
  #define __ISO_C_VISIBLE 1990
 #elif _POSIX_C_SOURCE >= 199009
  #define __POSIX_VISIBLE 199009
  #define __ISO_C_VISIBLE 1990
 #else
  #define __POSIX_VISIBLE 198808
  #define __ISO_C_VISIBLE 0
 #endif
#else
 #if defined(_ANSI_SOURCE)
  #define __POSIX_VISIBLE 0
  #define __XSI_VISIBLE 0
  #define __BSD_VISIBLE 0
  #define __ISO_C_VISIBLE 1990
 #elif defined(_C99_SOURCE)
  #define __POSIX_VISIBLE 0
  #define __XSI_VISIBLE 0
  #define __BSD_VISIBLE 0
  #define __ISO_C_VISIBLE 1999
 #elif defined(_C11_SOURCE)
  #define __POSIX_VISIBLE 0
  #define __XSI_VISIBLE 0
  #define __BSD_VISIBLE 0
  #define __ISO_C_VISIBLE 2011
 #else
  #define __POSIX_VISIBLE 200809
  #define __XSI_VISIBLE 700
  #define __BSD_VISIBLE 1
  #define __ISO_C_VISIBLE 2011
 #endif
#endif

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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

Re: __STRICT_ANSI__ and stdio.h

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]

On Dec 15 02:17, KIMURA Masaru wrote:
> Hi,
> 
> >> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
> >
> > Cygwin is using newlib, newlib is BSD based.  We introduced the
> > compatibility checking macros from FreeBSD lately.
> 
> i roughly checked FreeBSD include/stdio.h and sys/sys/cdefs.h.
> https://github.com/freebsd/freebsd/blob/master/include/stdio.h
> https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h
> 
> it looks very different to newlib's.

Yes, it does.  Newlib has a long history diverging from the BSDs to
support embedded systems in the first place, and compatibility checking
macros other than __STRICT_ANSI__ and __POSIX_SOURCE weren't much of a
concern for a long time.

> FreeBSD has visibility for popen()/pclose() if __POSIX_VISIBLE >= 199209,
> it looks no checking about __STRICT_ANSI__ in their cdefs.h.

Yeah, that's history as described above.  popen gets declared in newlib
if __STRICT_ANSI__ is not defined right now.

> only one thing i worried about is _ANSI_SOURCE in their cdefs.h,
> (b/c i don't understand where _ANSI_SOURCE comes from...)
> but it looks _POSIX_C_SOURCE wins anyway.
> for ease to see, i'd attach simplified their cdefs.h for their
> visibility handling.

I don't see the difference, see below.  The big differences in newlib
are the additional handling of _GNU_SOURCE and the old usage of
__STRICT_ANSI__ in some circumstances which haven't been replaced by another
usage of compatibility macros yet.

But here's the deal:  Newlib is a volunteer-driven project.  If the
compatiblity checking macros are not correct or not correctly used in
all circumstances, newlib is happily open to patches.  Just send them
to the newlib AT sourceware DOT org mailing list.

> #if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 1
>  #undef _POSIX_C_SOURCE
>  #define _POSIX_C_SOURCE 199009
> #endif

Same in Newlib's sys/cdefs.h.

> #if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 2
>  #undef _POSIX_C_SOURCE
>  #define _POSIX_C_SOURCE 199209
> #endif

Ditto.

> #ifdef _XOPEN_SOURCE
>  #if _XOPEN_SOURCE - 0 >= 700
>   #define __XSI_VISIBLE 700
>   #undef _POSIX_C_SOURCE
>   #define _POSIX_C_SOURCE 200809
>  #elif _XOPEN_SOURCE - 0 >= 600
>   #define __XSI_VISIBLE 600
>   #undef _POSIX_C_SOURCE
>   #define _POSIX_C_SOURCE 200112
>  #elif _XOPEN_SOURCE - 0 >= 500
>   #define __XSI_VISIBLE 500
>   #undef _POSIX_C_SOURCE
>   #define _POSIX_C_SOURCE 199506
>  #endif
> #endif

Ditto.

> #if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE)
>  #define _POSIX_C_SOURCE 198808
> #endif

Ditto.

> #ifdef _POSIX_C_SOURCE
>  #if _POSIX_C_SOURCE >= 200809
>   #define __POSIX_VISIBLE 200809
>   #define __ISO_C_VISIBLE 1999
>  #elif _POSIX_C_SOURCE >= 200112
>   #define __POSIX_VISIBLE 200112
>   #define __ISO_C_VISIBLE 1999
>  #elif _POSIX_C_SOURCE >= 199506
>   #define __POSIX_VISIBLE 199506
>   #define __ISO_C_VISIBLE 1990
>  #elif _POSIX_C_SOURCE >= 199309
>   #define __POSIX_VISIBLE 199309
>   #define __ISO_C_VISIBLE 1990
>  #elif _POSIX_C_SOURCE >= 199209
>   #define __POSIX_VISIBLE 199209
>   #define __ISO_C_VISIBLE 1990
>  #elif _POSIX_C_SOURCE >= 199009
>   #define __POSIX_VISIBLE 199009
>   #define __ISO_C_VISIBLE 1990
>  #else
>   #define __POSIX_VISIBLE 198808
>   #define __ISO_C_VISIBLE 0
>  #endif
> #else
>  #if defined(_ANSI_SOURCE)
>   #define __POSIX_VISIBLE 0
>   #define __XSI_VISIBLE 0
>   #define __BSD_VISIBLE 0
>   #define __ISO_C_VISIBLE 1990
>  #elif defined(_C99_SOURCE)
>   #define __POSIX_VISIBLE 0
>   #define __XSI_VISIBLE 0
>   #define __BSD_VISIBLE 0
>   #define __ISO_C_VISIBLE 1999
>  #elif defined(_C11_SOURCE)
>   #define __POSIX_VISIBLE 0
>   #define __XSI_VISIBLE 0
>   #define __BSD_VISIBLE 0
>   #define __ISO_C_VISIBLE 2011
>  #else
>   #define __POSIX_VISIBLE 200809
>   #define __XSI_VISIBLE 700
>   #define __BSD_VISIBLE 1
>   #define __ISO_C_VISIBLE 2011
>  #endif
> #endif

Ditto.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: __STRICT_ANSI__ and stdio.h

[KIMURA Masaru]

Hi,

>> >> is cygwin's __STRICT_ANSI__ and stdio.h behavior not so compatible to glibc's?
>> >
>> > Cygwin is using newlib, newlib is BSD based.  We introduced the
>> > compatibility checking macros from FreeBSD lately.
>>
>> i roughly checked FreeBSD include/stdio.h and sys/sys/cdefs.h.
>> https://github.com/freebsd/freebsd/blob/master/include/stdio.h
>> https://github.com/freebsd/freebsd/blob/master/sys/sys/cdefs.h
>>
>> it looks very different to newlib's.
>
> Yes, it does.  Newlib has a long history diverging from the BSDs to
> support embedded systems in the first place, and compatibility checking
> macros other than __STRICT_ANSI__ and __POSIX_SOURCE weren't much of a
> concern for a long time.
>
>> FreeBSD has visibility for popen()/pclose() if __POSIX_VISIBLE >= 199209,
>> it looks no checking about __STRICT_ANSI__ in their cdefs.h.
>
> Yeah, that's history as described above.  popen gets declared in newlib
> if __STRICT_ANSI__ is not defined right now.
>
>> only one thing i worried about is _ANSI_SOURCE in their cdefs.h,
>> (b/c i don't understand where _ANSI_SOURCE comes from...)
>> but it looks _POSIX_C_SOURCE wins anyway.
>> for ease to see, i'd attach simplified their cdefs.h for their
>> visibility handling.
>
> I don't see the difference, see below.  The big differences in newlib
> are the additional handling of _GNU_SOURCE and the old usage of
> __STRICT_ANSI__ in some circumstances which haven't been replaced by another
> usage of compatibility macros yet.
>
> But here's the deal:  Newlib is a volunteer-driven project.  If the
> compatiblity checking macros are not correct or not correctly used in
> all circumstances, newlib is happily open to patches.  Just send them
> to the newlib AT sourceware DOT org mailing list.
>
>> #if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE == 1
>>  #undef _POSIX_C_SOURCE
>>  #define _POSIX_C_SOURCE 199009
>> #endif
>
> Same in Newlib's sys/cdefs.h.
>
> [SNIP]

ah, i didn't check newlib's sys/cdefs.h.
thank you for correcting my misunderstanding.

apart from standard compliance correctness,
it's good to hear newlib can deal it.
if i had more spare time to dive its source, i'd like to do it.

Peace,

--
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