[cfe-dev] Clang++ always defines _GNU_SOURCE
Joerg Sonnenberger via cfe-dev
cfe-dev at lists.llvm.org
Tue Jun 14 15:51:46 PDT 2016
On Tue, Jun 14, 2016 at 10:10:27PM +0800, Lei Zhang wrote:
> 2016-06-14 21:40 GMT+08:00 Joerg Sonnenberger via cfe-dev
> <cfe-dev at lists.llvm.org>:
> > On Tue, Jun 14, 2016 at 08:28:33PM +0800, Lei Zhang wrote:
> >> 2016-06-14 20:22 GMT+08:00 Lei Zhang <zhanglei.april at gmail.com>:
> >> > 2016-06-14 20:12 GMT+08:00 Joerg Sonnenberger via cfe-dev
> >> > <cfe-dev at lists.llvm.org>:
> >> >> Compared to breaking lots of applications that expect the GNU symbols by
> >> >> default?
> >> >
> >> > That's a valid point. OTOH, should we encourage applications to use
> >> > GNU symbols with out explicitly defining _GNU_SOURCE? Then what's the
> >> > point of such a macro?
> >>
> >> BTW, _GNU_SOURCE is *not* unconditionally defined by gcc/clang when
> >> compiling C code on Linux.
> >
> > You can't change the visibility macros after the first header has been
> > included. C language mode doesn't ship with a C library set that
> > requires many of the non-standard / non-ISO functions. That's completely
> > different from C++, where many typical STL includes include more than
> > the functions supported by ISO C (and the default namespace with glibc).
> > That's why it is pushed by default.
>
> Perhaps I'm not seeing the whole picture, but it looks to me that
> using finer-grained visibility macros like _BSD_SOURCE,
> _POSIX_C_SOURCE, etc does *not* violates your points. We could still
> expose those non-standard functions without blindly defining
> _GNU_SOURCE, don't we?
Except when the standards conflict or the other already specified
something else, e.g. POSIX 2004.
Joerg
More information about the cfe-dev
mailing list