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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=LDVHxUUp3JRWNXDA
	INVUMGPGRnfKnkGYrchg8PdcBSSvygzJbb1JUe+tA8/TtagU361x9kUDdmeG7R64
	MUm+ny9A3IXoswUZZCFs3KqLdA1/80dwtbI+wdAJ2B0imPm9mmtMMhvoYetTeru0
	rBBhRJpGb4dQndL6S3y/6CDXnCc=
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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=POzO3JIz9RTtOYL1LOTgfq
	85ajg=; b=MqlLs5/WhjoP8OFyjIppCKwenyUa3fqXjYCDlyIH7AbGmagzz6tMyM
	N2vV0dTZkvXf3ZBpu3jSd7nGyZsWYC+9w8cEt63dCOpxuq0RrUxUO2hOQu+h76zL
	7oPvka1QQFGR6izeaC9jrAr5Sq7Ky6aHTAFNd2E4jMPxMCSmRtg1g=
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.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Requirements, H*R:D*ca, advised
X-HELO: smtp-out-so.shaw.ca
Reply-To: Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Subject: Re: Why does -std=c++11 hide certain function calls
To: cygwin AT cygwin DOT com
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>
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Openpgp: preference=signencrypt
Message-ID: <258a1db5-4151-33c7-5db6-2a06f82975c5@SystematicSw.ab.ca>
Date: Wed, 5 Sep 2018 14:41:23 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAJn6YFD+RjY60kDZU7pQP7BHpdxCDGGwg+2yeOM7=XKVER_C1Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

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