Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Jan 2017 22:52:19 +0000
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: libstdc++ namespace pollution

On 3 January 2017 at 21:35, Rich Felker <dalias@...c.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@...c.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() {}

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.