Date: Wed, 29 Aug 2012 11:23:19 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: Best bikeshed ever (feature test macros) On Wed, Aug 29, 2012 at 10:08:34AM -0500, Bobby Bingham wrote: > On Wed, Aug 29, 2012 at 9:43 AM, Rich Felker <dalias@...ifal.cx> wrote: > > > > 3. Make as much software as possible "just work". > > > > I would much rather that the software worked because it was correct, > and not because musl worked around its brokenness. > > I realize this isn't a very practical viewpoint, especially if you > hope to have musl see any adoption, but you asked for opinions and I > think broken software should be allowed to break. The fixes belong in > those projects, not worked around in musl. This is wishful thinking, > but perhaps if we had a major libc that exposed this brokenness by > default, it would raise awareness among the authors of other software > and they would fix it. Unfortunately a large portion of projects that need extension functionality of any sort are unwilling to "fix" the issue, because the existing libcs are so broken. For example, if you want the kitchen sink on some (most?) BSDs, the only way to get it is to omit all feature test macros entirely. This makes project maintainers very wary of using feature test macros. In principle, musl's approach changed from "make sure broken programs break as often as possible" to "be as compatible as possible within the letter of the specs" a long time ago. For example with expose MAP_ANONYMOUS by default even though it's officially an extension, because MAP_* is in the reserved namespace for mman.h, making it legal (albeit of course not required) to expose it. There are several other places where we do the same with nonstandard fields in structures; if the field prefix (e.g. st_*, etc.) is in the reserved namespace, we take advantage of that to accommodate applications as much as possible. I originally wanted to pressure broken programs to fix their breakage. But the goal of musl is to fix libc, not to fix every broken program out there. And I don't think we can do both at the same time... > With glibc providing the kitchen sink, they have very little incentive > to do anything about it, if they're even aware of it in the first > place. Actually glibc does something more like #3, but worse. By default it only standard C functions and unixy stuff that was in _legacy_ unix. And maybe some random subset of newer stuff they like. It's a very ugly situation to be dealing with, much uglier than "the kitchen sink" since some important, desirable interfaces are missing. > I vote for #1. Noted. :-) Rich
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.