Re: libstdc++ namespace pollution

[Rich Felker <dalias@libc.org>]

On Tue, Jan 03, 2017 at 10:52:19PM +0000, Justin Cormack wrote:
> On 3 January 2017 at 21:35, Rich Felker <dalias@libc.org> wrote:
> > On Tue, Jan 03, 2017 at 09:16:29PM +0000, Justin Cormack wrote:
> >> On 3 January 2017 at 18:29, Rich Felker <dalias@libc.org> wrote:
> >> > On Tue, Jan 03, 2017 at 05:44:47PM +0000, Justin Cormack wrote:
> >> >> I have been trying to build a C++ program recently, and came across
> >> >> the issue that
> >> >>
> >> >> 1. libstdc++ always defines _GNU_SOURCE see
> >> >> https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined
> >> >> 2. Musl defines pretty much everything once _GNU_SOURCE is defined
> >> >
> >> > So does glibc. :)
> >>
> >> This particular issue only happens with Musl, it includes more...
> >
> > That might be a bug/unwanted behavior on musl's side then. Could you
> > help me check? I'd be happy to remove namespace-polluting cruft that's
> > not actually needed to meet what applications can reasonably expect
> > from _GNU_SOURCE.
> >
> 
> This minimal test case compiles with c++ on Debian but not on Alpine:
> 
> #include <signal.h>
> 
> class ArgumentParser_x64 {
>   enum Register {
>     REG_A,
>     REG_B,
>     REG_C,
>     REG_D,
>     REG_SI,
>     REG_DI,
>     REG_BP,
>     REG_SP,
>     REG_8,
>     REG_9,
>     REG_10,
>     REG_11,
>     REG_12,
>     REG_13,
>     REG_14,
>     REG_15,
>     REG_RIP,
>   };
> };
> 
> main() {}

I see. It's a bit of luck that it happens to work on glibc, I think --
they define the REG_* identifiers as enum constants and then #define
them to themselves in order to satisfy programs which are checking for
their presence with #ifdef. So while the above code has macros
clashing with the identifier names it wants to use, they end up being
benign because they're defined to themselves.

In general I don't do this (the enum approach) in musl because (1) I
don't like enums, and (2) it breaks things that want to use the macros
in preprocessor #if conditionals. However for macros like this that
aren't specified by any standard and which are fundamentally namespace
pollution, it seems like a better approach, so I'm not opposed to
switching. We should probably do the same on all affected archs if we
do.

Rich