From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10875 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:33:21 -0500 Message-ID: <20170103233321.GK1555@brightrain.aerifal.cx> References: <20170103182908.GH1555@brightrain.aerifal.cx> <20170103213552.GI1555@brightrain.aerifal.cx> <20170103231728.GJ1555@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 1483486420 31572 195.159.176.226 (3 Jan 2017 23:33:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2017 23:33:40 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10888-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 04 00:33:36 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 1cOYaB-00079i-Ij for gllmg-musl@m.gmane.org; Wed, 04 Jan 2017 00:33:31 +0100 Original-Received: (qmail 21950 invoked by uid 550); 3 Jan 2017 23:33:33 -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 21932 invoked from network); 3 Jan 2017 23:33:33 -0000 Content-Disposition: inline In-Reply-To: <20170103231728.GJ1555@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10875 Archived-At: 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. Rich