From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81132 invoked by alias); 6 Sep 2018 06:45:56 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 80860 invoked by uid 89); 6 Sep 2018 06:45:36 -0000 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 Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Sep 2018 06:45:33 +0000 Received: by mail-wm0-f65.google.com with SMTP id o18-v6so10016531wmc.0 for ; Wed, 05 Sep 2018 23:45:33 -0700 (PDT) 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: <55fcf4b3-5fd0-8fa1-6669-5a93a14c863e@t-online.de> <258a1db5-4151-33c7-5db6-2a06f82975c5@SystematicSw.ab.ca> In-Reply-To: <258a1db5-4151-33c7-5db6-2a06f82975c5@SystematicSw.ab.ca> From: John Selbie Date: Thu, 06 Sep 2018 06:45:00 -0000 Message-ID: Subject: Re: Why does -std=c++11 hide certain function calls To: Brian.Inglis@systematicsw.ab.ca, cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00112.txt.bz2 > 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=3Dc* without any special language or library feature= s, in which case you may also want to add -pedantic or more restrictive options. Ahhhh=E2=80=A6. that was my mistake. I had erroneously assumed that not sp= ecifying -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 . 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 wrote: > On 2018-09-05 13:36, John Selbie wrote: > > On Wed, Sep 5, 2018 at 11:46 AM Hans-Bernhard Br=C3=B6ker wrote: > >> Am 05.09.2018 um 07:55 schrieb John Selbie: > >>> With this: g++ foo.cpp -c -std=3Dc++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=3Dgnu++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=3Dc++11 is meant and documented to do. It tur= ns > >> off all extensions to the standard language. And yes, that does inclu= de > >> extensions to the standard libary, up to and including POSIX-specific > >> content. > >> For what you want to do, std=3Dc++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, b= ut > > 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 >=3D 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=3Dgnu* (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=3Dc* 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