This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why does -std=c++11 hide certain function calls


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]