public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: __STRICT_ANSI__ and stdio.h
Date: Tue, 15 Dec 2015 09:30:00 -0000	[thread overview]
Message-ID: <20151215093020.GA12827@calimero.vinschen.de> (raw)
In-Reply-To: <CAPYQg33AHw4k9hU8kXbsM9WJ3-+9gr5cm1Ob1S7YXO8MP3LGdQ@mail.gmail.com>

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

  reply	other threads:[~2015-12-15  9:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12  7:51 KIMURA Masaru
2015-12-13 16:51 ` cyg Simple
2015-12-14  4:56   ` KIMURA Masaru
2015-12-14  4:58     ` KIMURA Masaru
2015-12-14 13:34     ` cyg Simple
2015-12-14 14:06 ` Corinna Vinschen
2015-12-14 17:17   ` KIMURA Masaru
2015-12-15  9:30     ` Corinna Vinschen [this message]
2015-12-15 15:58       ` KIMURA Masaru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151215093020.GA12827@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).