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

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

[John Selbie]

Updating Stuntman (Open source Stun Server) from C++ to modern C++.  I ran
into an issue.
This code:

    #include <stdio.h>
    #include <sys/socket.h>
    #include <netdb.h>
    int some_networking_code()
    {
       addrinfo* addr = NULL;
       int flags = AI_NUMERICHOST;
       return 0;
    }

Compiles fine everywhere: with: g++ foo.cpp -c

With this: g++ foo.cpp -c -std=c++11
It compiles fine everywhere else, except CygWin.  Output on Cygwin:

    foo.cpp: In function ‘int some_networking_code()’:
    foo.cpp:8:4: error: ‘addrinfo’ was not declared in this scope
    foo.cpp:9:16: error: ‘AI_NUMERICHOST’ was not declared in this scope

Digging in further, I see that /usr/include/netdb.h has macros for blocking
declarataion of these items:

    #if __POSIX_VISIBLE >= 200112 && !defined(__INSIDE_CYGWIN_NET__)
    struct addrinfo {
      int             ai_flags;             /* input flags */
      … <deleted for brevity>
    #endif

And when the macros are inspected with:  g++ foo.cpp -c -std=c++11 -dM -E |
grep POSIX_VIS
We can see that:
    #define __POSIX_VISIBLE 0

Which explains the compiler output.
Searching the mailing list archives, I see I'm not the first to observe
something this:
    http://sourceware.org/ml/cygwin/2017-01/msg00392.html

Yes, switching to -std=gnu++11 or adding  -D_DEFAULT_SOURCE to the command
line 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? When the goal of Cygwin
is to allow Unix code to be rebuilt for Windows easily, it feels dirty that
my Makefile will need Cygwin specific adjustments.  Why not just take out
the __POSIX_VISIBLE>=200112 check altogether?  If I'm missing the point of
something obvious, I'd be open to be educated on this.

Thanks,
jselbie

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

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

[Hans-Bernhard Bröker]

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

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

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

[John Selbie]

Thanks for the response.

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.

jrs


On Wed, Sep 5, 2018 at 11:46 AM Hans-Bernhard Bröker <HBBroeker@t-online.de>
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 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.
>
> --
> 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

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

[Brian Inglis]

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

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

[Doug Henderson]

On Wed, 5 Sep 2018 at 14:41, Brian Inglis  wrote:

>     _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE"

Relavent xkcd - https://xkcd.com/927/

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

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

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

[John Selbie]

> 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.Inglis@systematicsw.ab.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

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

[Csaba Raduly]

Hi John,

On Thu, Sep 6, 2018 at 8:45 AM, John Selbie  wrote:
> Ahhhh…. that was my mistake.  I had erroneously assumed that not specifying
> -std would result in the oldest version of C++.

This depends on the compiler. For a long time, the default C++ dialect
used by both GCC and clang was C++98.
Since GCC 6.0 and clang 6.0.0, the default C++ dialect is now C++14

https://gcc.gnu.org/gcc-6/changes.html
https://isocpp.org/blog/2018/03/clang-6.0.0-released


Csaba
-- 
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)

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

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

[Jeffrey Walton]

On Thu, Sep 6, 2018 at 2:45 AM, John Selbie <jselbie@gmail.com> wrote:
>> 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>.

By default GCC uses a -std=gnu++NN, not -std=c++NN. So you are getting
mostly the latest C++ but it is GNU's flavor with non-standard things
like Variable Length Arrays (VLA's).

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

Cygwin and Newlib conflate options in unexpected ways.

I think they are making incorrect leaps about options. For example if
you want Posix you may not want a GCC extension like VLA's. I doubt it
will change, though. You just have to work around it.

Jeff

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