Re: libstdc++ namespace pollution

[Rich Felker <dalias@libc.org>]

On Wed, Jan 04, 2017 at 02:33:46PM +0000, Justin Cormack wrote:
> Almost, misses REG_R8 etc but
> 
> sed 's/#define  *\(REG_[A-Z_0-9]\{1,\}\)  *\([0-9]\{1,\}\)/enum { \1 =
> \2 };\n#define \1 \1/'
> 
> works for me yes

OK, I'll commit the resulting patch then.

Rich


> On 3 January 2017 at 23:53, Rich Felker <dalias@libc.org> wrote:
> > On Tue, Jan 03, 2017 at 06:33:21PM -0500, Rich Felker wrote:
> >> On Tue, Jan 03, 2017 at 06:17:28PM -0500, Rich Felker wrote:
> >> > 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.
> >>
> >> After a quick glance, looks like this issue only affects x86[_64].
> >> I'll see if I can prepare a simple patch with a clean idiom we can
> >> repeat elsewhere if needed.
> >
> > Does this sed script, run on bits/signal.h, work for you?
> >
> > sed 's/#define  *\(REG_[A-Z_]\{1,\}\)  *\([0-9]\{1,\}\)/enum { \1 = \2 };\n#define \1 \1/'
> >
> > I like this approach better than trying to pretty-format a big enum by
> > hand because it doesn't risk mistakes. If a single big enum would be
> > preferred, maybe we could do a similar sed for the body of the enum,
> > but I actually don't really like the GNU-style interleaved
> > enum-and-#define.
> >
> > Rich