[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170103233321.GK1555@brightrain.aerifal.cx>
Date: Tue, 3 Jan 2017 18:33:21 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: libstdc++ namespace pollution
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@...c.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@...c.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.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
