* libstdc++ namespace pollution
@ 2017-01-03 17:44 Justin Cormack
2017-01-03 18:29 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Justin Cormack @ 2017-01-03 17:44 UTC (permalink / raw)
To: musl
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
In this case the issue was that the program included <signal.h> and
then the register names REG_RIP etc were #defined as numeric
constants, while the program wanted to use them as names for an enum.
Does anyone have any recommendations (wondering about trying clang
libc++ perhaps)?
Justin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 17:44 libstdc++ namespace pollution Justin Cormack
@ 2017-01-03 18:29 ` Rich Felker
2017-01-03 21:16 ` Justin Cormack
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2017-01-03 18:29 UTC (permalink / raw)
To: musl
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. :)
> In this case the issue was that the program included <signal.h> and
> then the register names REG_RIP etc were #defined as numeric
> constants, while the program wanted to use them as names for an enum.
>
> Does anyone have any recommendations (wondering about trying clang
> libc++ perhaps)?
This is a known issue that the gcc people want to fix, I think. It
might be possible to patch it out already it you're prepared to track
down things that break and fix them.
Rich
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 18:29 ` Rich Felker
@ 2017-01-03 21:16 ` Justin Cormack
2017-01-03 21:35 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Justin Cormack @ 2017-01-03 21:16 UTC (permalink / raw)
To: musl
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...
>> In this case the issue was that the program included <signal.h> and
>> then the register names REG_RIP etc were #defined as numeric
>> constants, while the program wanted to use them as names for an enum.
>>
>> Does anyone have any recommendations (wondering about trying clang
>> libc++ perhaps)?
>
> This is a known issue that the gcc people want to fix, I think. It
> might be possible to patch it out already it you're prepared to track
> down things that break and fix them.
Ok.
Justin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 21:16 ` Justin Cormack
@ 2017-01-03 21:35 ` Rich Felker
2017-01-03 22:52 ` Justin Cormack
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2017-01-03 21:35 UTC (permalink / raw)
To: musl
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.
Rich
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 21:35 ` Rich Felker
@ 2017-01-03 22:52 ` Justin Cormack
2017-01-03 23:17 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Justin Cormack @ 2017-01-03 22:52 UTC (permalink / raw)
To: musl
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() {}
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 22:52 ` Justin Cormack
@ 2017-01-03 23:17 ` Rich Felker
2017-01-03 23:33 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2017-01-03 23:17 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 23:17 ` Rich Felker
@ 2017-01-03 23:33 ` Rich Felker
2017-01-03 23:53 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2017-01-03 23:33 UTC (permalink / raw)
To: musl
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.
Rich
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 23:33 ` Rich Felker
@ 2017-01-03 23:53 ` Rich Felker
2017-01-04 14:33 ` Justin Cormack
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2017-01-03 23:53 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-03 23:53 ` Rich Felker
@ 2017-01-04 14:33 ` Justin Cormack
2017-01-04 23:05 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Justin Cormack @ 2017-01-04 14:33 UTC (permalink / raw)
To: musl
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@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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution
2017-01-04 14:33 ` Justin Cormack
@ 2017-01-04 23:05 ` Rich Felker
0 siblings, 0 replies; 10+ messages in thread
From: Rich Felker @ 2017-01-04 23:05 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-01-04 23:05 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-03 17:44 libstdc++ namespace pollution Justin Cormack
2017-01-03 18:29 ` Rich Felker
2017-01-03 21:16 ` Justin Cormack
2017-01-03 21:35 ` Rich Felker
2017-01-03 22:52 ` Justin Cormack
2017-01-03 23:17 ` Rich Felker
2017-01-03 23:33 ` Rich Felker
2017-01-03 23:53 ` Rich Felker
2017-01-04 14:33 ` Justin Cormack
2017-01-04 23:05 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).