* libstdc++ namespace pollution @ 2017-01-03 17:44 Justin Cormack 2017-01-03 18:29 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Justin Cormack @ 2017-01-03 17:44 UTC (permalink / raw) To: musl 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 In this case the issue was that the program included <signal.h> and then the register names REG_RIP etc were #defined as numeric constants, while the program wanted to use them as names for an enum. Does anyone have any recommendations (wondering about trying clang libc++ perhaps)? Justin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 17:44 libstdc++ namespace pollution Justin Cormack @ 2017-01-03 18:29 ` Rich Felker 2017-01-03 21:16 ` Justin Cormack 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-01-03 18:29 UTC (permalink / raw) To: musl 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. :) > In this case the issue was that the program included <signal.h> and > then the register names REG_RIP etc were #defined as numeric > constants, while the program wanted to use them as names for an enum. > > Does anyone have any recommendations (wondering about trying clang > libc++ perhaps)? This is a known issue that the gcc people want to fix, I think. It might be possible to patch it out already it you're prepared to track down things that break and fix them. Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 18:29 ` Rich Felker @ 2017-01-03 21:16 ` Justin Cormack 2017-01-03 21:35 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Justin Cormack @ 2017-01-03 21:16 UTC (permalink / raw) To: musl On 3 January 2017 at 18:29, Rich Felker <dalias@libc.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... >> In this case the issue was that the program included <signal.h> and >> then the register names REG_RIP etc were #defined as numeric >> constants, while the program wanted to use them as names for an enum. >> >> Does anyone have any recommendations (wondering about trying clang >> libc++ perhaps)? > > This is a known issue that the gcc people want to fix, I think. It > might be possible to patch it out already it you're prepared to track > down things that break and fix them. Ok. Justin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 21:16 ` Justin Cormack @ 2017-01-03 21:35 ` Rich Felker 2017-01-03 22:52 ` Justin Cormack 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-01-03 21:35 UTC (permalink / raw) To: musl On Tue, Jan 03, 2017 at 09:16:29PM +0000, Justin Cormack wrote: > On 3 January 2017 at 18:29, Rich Felker <dalias@libc.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. Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 21:35 ` Rich Felker @ 2017-01-03 22:52 ` Justin Cormack 2017-01-03 23:17 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Justin Cormack @ 2017-01-03 22:52 UTC (permalink / raw) To: musl On 3 January 2017 at 21:35, Rich Felker <dalias@libc.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@libc.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() {} ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 22:52 ` Justin Cormack @ 2017-01-03 23:17 ` Rich Felker 2017-01-03 23:33 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-01-03 23:17 UTC (permalink / raw) To: musl On Tue, Jan 03, 2017 at 10:52:19PM +0000, Justin Cormack wrote: > On 3 January 2017 at 21:35, Rich Felker <dalias@libc.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@libc.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() {} 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 23:17 ` Rich Felker @ 2017-01-03 23:33 ` Rich Felker 2017-01-03 23:53 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-01-03 23:33 UTC (permalink / raw) To: musl 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 <dalias@libc.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@libc.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() {} > > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 23:33 ` Rich Felker @ 2017-01-03 23:53 ` Rich Felker 2017-01-04 14:33 ` Justin Cormack 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2017-01-03 23:53 UTC (permalink / raw) To: musl 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 <dalias@libc.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@libc.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() {} > > > > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-03 23:53 ` Rich Felker @ 2017-01-04 14:33 ` Justin Cormack 2017-01-04 23:05 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Justin Cormack @ 2017-01-04 14:33 UTC (permalink / raw) To: musl 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 <dalias@libc.org> 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 <dalias@libc.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@libc.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() {} >> > >> > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: libstdc++ namespace pollution 2017-01-04 14:33 ` Justin Cormack @ 2017-01-04 23:05 ` Rich Felker 0 siblings, 0 replies; 10+ messages in thread From: Rich Felker @ 2017-01-04 23:05 UTC (permalink / raw) To: musl On Wed, Jan 04, 2017 at 02:33:46PM +0000, Justin Cormack wrote: > 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 OK, I'll commit the resulting patch then. Rich > On 3 January 2017 at 23:53, Rich Felker <dalias@libc.org> 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 <dalias@libc.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@libc.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() {} > >> > > >> > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-01-04 23:05 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-03 17:44 libstdc++ namespace pollution Justin Cormack 2017-01-03 18:29 ` Rich Felker 2017-01-03 21:16 ` Justin Cormack 2017-01-03 21:35 ` Rich Felker 2017-01-03 22:52 ` Justin Cormack 2017-01-03 23:17 ` Rich Felker 2017-01-03 23:33 ` Rich Felker 2017-01-03 23:53 ` Rich Felker 2017-01-04 14:33 ` Justin Cormack 2017-01-04 23:05 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).