From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1789 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Best bikeshed ever (feature test macros) Date: Wed, 29 Aug 2012 11:23:19 -0400 Message-ID: <20120829152319.GW27715@brightrain.aerifal.cx> References: <20120824214138.GA17792@brightrain.aerifal.cx> <20120829073442.66c72367@gmail.com> <20120829134939.GS27715@brightrain.aerifal.cx> <503E20B9.7060705@purdue.edu> <20120829144347.GU27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1346253690 31218 80.91.229.3 (29 Aug 2012 15:21:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2012 15:21:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1790-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 29 17:21:26 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T6k57-0007fm-L5 for gllmg-musl@plane.gmane.org; Wed, 29 Aug 2012 17:21:25 +0200 Original-Received: (qmail 28003 invoked by uid 550); 29 Aug 2012 15:21:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 27994 invoked from network); 29 Aug 2012 15:21:22 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1789 Archived-At: On Wed, Aug 29, 2012 at 10:08:34AM -0500, Bobby Bingham wrote: > On Wed, Aug 29, 2012 at 9:43 AM, Rich Felker 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