From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10880 Path: news.gmane.org!.POSTED!not-for-mail From: Justin Cormack Newsgroups: gmane.linux.lib.musl.general Subject: Re: libstdc++ namespace pollution Date: Wed, 4 Jan 2017 14:33:46 +0000 Message-ID: References: <20170103182908.GH1555@brightrain.aerifal.cx> <20170103213552.GI1555@brightrain.aerifal.cx> <20170103231728.GJ1555@brightrain.aerifal.cx> <20170103233321.GK1555@brightrain.aerifal.cx> <20170103235319.GL1555@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1483540443 30353 195.159.176.226 (4 Jan 2017 14:34:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 14:34:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10893-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 04 15:33:58 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 1cOmdZ-0007KW-MU for gllmg-musl@m.gmane.org; Wed, 04 Jan 2017 15:33:57 +0100 Original-Received: (qmail 28186 invoked by uid 550); 4 Jan 2017 14:33:59 -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 28168 invoked from network); 4 Jan 2017 14:33:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=specialbusservice.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=JCq76JVlhKxZxHXV3pCctTkQuewFlF9iqbTLrygZlIQ=; b=RsZGceISOQ6mAgYCiHqVInZLPEm70JacqW+qw/EdLdsblyYWqpgNHOdnExFTWaUd1I USgdyFU3G2R8gk5Zi3NRXSYtrc+O4iZmV4qJ7/ZBM2i/ifv5fUINF5fYosAdBPMKBXMQ lrdT1a7ZaW+wokc1ufHRYeT1S09s0RNmJDIyw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=JCq76JVlhKxZxHXV3pCctTkQuewFlF9iqbTLrygZlIQ=; b=HSdGM+YIXGRbSFNVbQSK5Z+1TUhcFHQ0KuDSrQSgcsN9hfwgnsnoC+Ttw2HI3GG161 Kz1nFX5GNIiDdeOPqRz3DOksmG+mB9W8s+jSS89dTPrgZHhoBLTbdyRzGbQwRJTnUGXX xvYsVZCl9JLTGa9y7tfof9ln6MBtmEuz3aDh2b1RTfiOqG8YzPL3AlehqTqekMMHCsEg 8OfHOjwuzJYPAfuNJ573qtj/ekMVtFuiGCe4Q7r1O4Zq7XCy1cV2H+fwM6xbp6JSuMDH LlzBDIMNwE8C92FvbkamczkKu8Uej5YBkgZKYPNO4zWx9Sj63qnnRO2Uom0aJFREBChk bj/w== X-Gm-Message-State: AIkVDXJ3uG8eEOZb017qGcXFAXflB1kYH3otyf9PZwQxzPPmWZMdx59KegSqYli/mGWJmkursqJtZkOnojkrIA== X-Received: by 10.31.232.198 with SMTP id f189mr23075198vkh.85.1483540426928; Wed, 04 Jan 2017 06:33:46 -0800 (PST) In-Reply-To: <20170103235319.GL1555@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10880 Archived-At: 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 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 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