From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10876 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: libstdc++ namespace pollution Date: Tue, 3 Jan 2017 18:53:19 -0500 Message-ID: <20170103235319.GL1555@brightrain.aerifal.cx> References: <20170103182908.GH1555@brightrain.aerifal.cx> <20170103213552.GI1555@brightrain.aerifal.cx> <20170103231728.GJ1555@brightrain.aerifal.cx> <20170103233321.GK1555@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1483487618 12254 195.159.176.226 (3 Jan 2017 23:53:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2017 23:53:38 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10889-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 04 00:53:34 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cOYtV-0001yV-JI for gllmg-musl@m.gmane.org; Wed, 04 Jan 2017 00:53:29 +0100 Original-Received: (qmail 3625 invoked by uid 550); 3 Jan 2017 23:53:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3606 invoked from network); 3 Jan 2017 23:53:31 -0000 Content-Disposition: inline In-Reply-To: <20170103233321.GK1555@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10876 Archived-At: 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 wrote: > > > > On Tue, Jan 03, 2017 at 09:16:29PM +0000, Justin Cormack wrote: > > > >> On 3 January 2017 at 18:29, Rich Felker 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 > > > > > > 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