X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type:content-transfer-encoding;
	q=dns; s=default; b=nwRN7dUyIPmk/zgW5N7Jghe4opXbmiT3ueutLV6Dt5g
	y9CouoRaXYajO2xfl3imZf1/jJ6/sfau51F072bRI7zrIpDRh2t7y5yuMDtzQZ31
	dve5nv6iUcNuB3vxeGMSrThTIxr/uMiHl/k9G2v+U0dTA3WY2CVOrCdAJybNGYqY
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type:content-transfer-encoding;
	s=default; bh=4ea3ZZorSStK9KOl+a1JioBZ9bI=; b=p0enZKATtkFneaRRM
	l2yoE4k/9eY+VlfdvYtPcB/gWopvFphgM5Avlv/b2JVK3II++YuXoi4ZRgsZcsUP
	n8dKMIj9oO5suvDy8YGiN0NtEXZ3xEumavA7r5rBmRUyaZWpc8i1WS7T9RaAYfQw
	Q/loDzwhs+6krDL/wkk9kYoIm8=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Requirements, erroneously, oldest, H*c:alternative
X-HELO:	mail-wm0-f65.google.com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+zJLarF74Ob8O6/J87TQ1Yyw24NpFFUYBuXOOfL8pSU=; b=Z6WvMrgYvXMkR8RXx8hnsFy36hD7iuercZA1lozoQEQQ0U/r/wVkLzw7ZE+HhRgJ4D 28d11EZUmbh+seLCnVPVCqtlQJKuzk6c3TVjzj69tcmEZaYLxZEhM1KeQOR1tAcWbjij PA6AEomFEmzQju+1+ozh/DzREohtGy8xt5nf22SHH8vXuGVxoKD/vGe/tttVBgf+10Xk /i3wSL0nIYYmMRyxJTyThcDJmhZD/J+E170m4FuR7OrifyGiijg/L4kKfVOE4frJAJ7O BL0vz5BiNjHEHftujkC5wB1u6HVmgfUo04hQZk0JuUcjHTXahmTBgCHtWWNhtG3PxAD5 A1Iw==
MIME-Version:	1.0
References:	<CAJn6YFD-zJoH4wtDaRq1EYYLwzWv_EYFWLGm+quj_RobFMv2Dg AT mail DOT gmail DOT com> <55fcf4b3-5fd0-8fa1-6669-5a93a14c863e AT t-online DOT de> <CAJn6YFD+RjY60kDZU7pQP7BHpdxCDGGwg+2yeOM7=XKVER_C1Q AT mail DOT gmail DOT com> <258a1db5-4151-33c7-5db6-2a06f82975c5 AT SystematicSw DOT ab DOT ca>
In-Reply-To:	<258a1db5-4151-33c7-5db6-2a06f82975c5@SystematicSw.ab.ca>
From:	John Selbie <jselbie AT gmail DOT com>
Date:	Wed, 5 Sep 2018 23:45:18 -0700
Message-ID:	<CAJn6YFDfNZdr=r+MbNQcRsPyEf8K0-=SXN13Qt5p-m9t=u24Bw@mail.gmail.com>
Subject:	Re: Why does -std=c++11 hide certain function calls
To:	Brian DOT Inglis AT systematicsw DOT ab DOT ca, cygwin AT cygwin DOT com
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id w866k6Su020477

> For Unixy builds, just don't specify -std. Only specify -std if you want
to ensure that builds will work with earlier standards, compilers, or
libraries, or for -std=c* without any special language or library features,
in which case you may also want to add -pedantic or more restrictive
options.

Ahhhh…. that was my mistake.  I had erroneously assumed that not specifying
-std would result in the oldest version of C++.  A quick check:

    $ g++ foo.cpp -c -dM -E  | grep cplus
    #define __cplusplus 201402L

I was compiling with C++ 14 the whole time.  And it appears that when -std
is used, the GNU defines are taken out, which ultimately influence how
POSIX_VISIBLE Is defined within <features.h>.

I'm not sure if I agree that -std should hide the functions from unix
headers. (tldr: unix headers are explicitly outside the c++ standard, so
the moment they are included, you might as well assume the developer wants
it all...)

But at last now I'm unblocked.  Thanks everyone.

jrs



On Wed, Sep 5, 2018 at 1:41 PM Brian Inglis <Brian DOT Inglis AT systematicsw DOT ab DOT ca>
wrote:

> On 2018-09-05 13:36, John Selbie wrote:
> > On Wed, Sep 5, 2018 at 11:46 AM Hans-Bernhard Bröker wrote:
> >> Am 05.09.2018 um 07:55 schrieb John Selbie:
> >>> With this: g++ foo.cpp -c -std=c++11
> >>> It compiles fine everywhere else, except CygWin.  Output on Cygwin:
> >> I'm afraid that may mean everywhere else is wrong.
> >>> Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the
> >>> command line works.
> >>> But I don't understand why the need to enforce these extensions to get
> >>> access to some of the most common unix libraries?
>
> >> Because that's what std=c++11 is meant and documented to do.  It turns
> >> off all extensions to the standard language.  And yes, that does include
> >> extensions to the standard libary, up to and including POSIX-specific
> >> content.
> >> For what you want to do, std=c++11 is simply the wrong setting.
>
> > But why is getaddrinfo (and its associated struct types and flag values)
> > considered a "language extension" and hidden via the __POSIX_VISIBILE
> > define when other function declarations in netdb.h (such as
> getservbyname)
> > are not?
> > I don't believe C++ has any formal support for networking.  So it's
> > surprising to see one networking function hidden "because its an
> > extension", but the other very related functions are not. Can you
> elaborate
> > on the decision process that makes it this way?  I honestly don't see
> how a
> > header file qualifies as a language extension, but instead just see it as
> > the interface for a pre-compiled library.
> > Is it because modern C++ is defined to support older POSIX functions, but
> > not newer ones?  Where is that in the standard?
> > As I said before, I'm wanting to be educated on this, because it could
> > influence how I view the writing and building of portable code now and in
> > the future.  But saying, "everywhere else but here is wrong" and because
> ",
> > doesn't help.
>
> Depends on how standards compliant the implementation and the developer
> are.
> Some(/all?) BSDs specify nothing, but POSIX and other standards specify
> feature
> test macros to enable access to those functions be defined for every C
> source
> module that requires them before any includes e.g. for Linux/GLIBC
> getaddrinfo(3):
>
> "Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
>
> getaddrinfo(), freeaddrinfo(), gai_strerror():
>     _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE"
>
> so to be guaranteed access to those functions, you should define and set
> one of
> those symbols, in each source file, build command line, or makefile, which
> -std=gnu* (or no -std flag) does for you. For Unixy builds, just don't
> specify
> -std. Only specify -std if you want to ensure that builds will work with
> earlier
> standards, compilers, or libraries, or for -std=c* without any special
> language
> or library features, in which case you may also want to add -pedantic or
> more
> restrictive options.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
>
> --
> 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
>
>

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

- Raw text -