public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: Why does -std=c++11 hide certain function calls
Date: Wed, 05 Sep 2018 20:41:00 -0000	[thread overview]
Message-ID: <258a1db5-4151-33c7-5db6-2a06f82975c5@SystematicSw.ab.ca> (raw)
In-Reply-To: <CAJn6YFD+RjY60kDZU7pQP7BHpdxCDGGwg+2yeOM7=XKVER_C1Q@mail.gmail.com>

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

  reply	other threads:[~2018-09-05 20:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05  5:56 John Selbie
2018-09-05 18:46 ` Hans-Bernhard Bröker
2018-09-05 19:36   ` John Selbie
2018-09-05 20:41     ` Brian Inglis [this message]
2018-09-06  0:14       ` Doug Henderson
2018-09-06  6:45       ` John Selbie
2018-09-06  9:18         ` Csaba Raduly
2018-09-06 14:07         ` Jeffrey Walton

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=258a1db5-4151-33c7-5db6-2a06f82975c5@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --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).