From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10874 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:17:28 -0500 Message-ID: <20170103231728.GJ1555@brightrain.aerifal.cx> References: <20170103182908.GH1555@brightrain.aerifal.cx> <20170103213552.GI1555@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 1483485467 28959 195.159.176.226 (3 Jan 2017 23:17:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2017 23:17:47 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10887-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 04 00:17:43 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 1cOYKp-0006ak-Tm for gllmg-musl@m.gmane.org; Wed, 04 Jan 2017 00:17:40 +0100 Original-Received: (qmail 11512 invoked by uid 550); 3 Jan 2017 23:17:40 -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 11491 invoked from network); 3 Jan 2017 23:17:40 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10874 Archived-At: 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. Rich