[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK4o1Wz=QwRR7bX4-x40ifPVE3KZ7YUNh_EU=6vvfdiEpQ=jgg@mail.gmail.com>
Date: Wed, 4 Jan 2017 14:33:46 +0000
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: libstdc++ namespace pollution
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
On 3 January 2017 at 23:53, Rich Felker <dalias@...c.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@...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.
>
> 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
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.
