From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3441 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.gnulib.bugs Subject: Re: gnulib cross-compiling issue with musl Date: Tue, 18 Jun 2013 14:42:24 -0400 Message-ID: <20130618184224.GW29800@brightrain.aerifal.cx> References: <20130618170305.GA30936@brightrain.aerifal.cx> <51C09BD9.8000503@cs.ucla.edu> <20130618180755.GV29800@brightrain.aerifal.cx> <51C0A7D2.4020605@cs.ucla.edu> 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 1371580966 24551 80.91.229.3 (18 Jun 2013 18:42:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Jun 2013 18:42:46 +0000 (UTC) Cc: Eric Blake , musl@lists.openwall.com, bug-gnulib@gnu.org To: Paul Eggert Original-X-From: musl-return-3445-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 18 20:42:47 2013 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 1Up0rf-0004k0-4V for gllmg-musl@plane.gmane.org; Tue, 18 Jun 2013 20:42:47 +0200 Original-Received: (qmail 8002 invoked by uid 550); 18 Jun 2013 18:42:46 -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 7994 invoked from network); 18 Jun 2013 18:42:46 -0000 Content-Disposition: inline In-Reply-To: <51C0A7D2.4020605@cs.ucla.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3441 gmane.comp.lib.gnulib.bugs:32948 Archived-At: On Tue, Jun 18, 2013 at 11:32:50AM -0700, Paul Eggert wrote: > On 06/18/13 11:07, Rich Felker wrote: > > > Of my two > > proposed fixes, the first would fix the issue on any future system > > that's not broken (not just existing ones), but would obviously not > > support future broken systems. > > But we're not talking about "future" systems here; we're merely talking > about unported-to systems, not all of which are future systems. > > Nor are we talking about "broken" systems; we're merely talking about > systems that do not conform to POSIX -- they may conform to C11, say, > without conforming to POSIX. > > So this first fix sounds problematic. I think the advent of new implementations that don't aim for at least a reasonable level of POSIX compatibility is fairly unlikely. But if you think it matters, you could add #elif defined _POSIX_VERSION containing the if(0), and leave #else at the end with #error. This should be entirely safe. > > The second proposed fix should support > > any future system, but would be a bit more costly, assuming it's even > > possible. > > That would be better, yes. But it'd be more work to implement than > method (3) would be. I agree that it would be more work, but if you really don't accept solution #1, I'd be happy to work with the gnulib team on figuring out what solution #2 would entail, whether it's possible, and implementing it. > > To revisit why I don't like your proposed fix, for every bug we could > > get fixed by making an easy way for applications to test "is this > > musl?", we would have something like 10 new bugs created by people > > doing that. This is not just speculation; it's based on questions we > > get on the list and on IRC. Your idea of using such a test in the form > > of "if (is_musl) assume_non_broken();" is the first proposed use of > > this form I've seen. Every other request for an easy "if (is_musl)" > > test have been from people who wanted to do something that would cause > > bad breakage with future versions of musl. > > I'm afraid I don't follow this reasoning. Are you saying that, > method (3) is OK here but its use here might encourage people > to use it in other places where it's not OK? If so, let's add > a comment warning people to use method (3) carefully. I'm saying that musl intentionally does not provide any macros to identify itself. Changing this to help gnulib do one correct thing would not be worth dealing with all the incorrect usages it would lead to. And I'm confident that presence of such a macro would lead to lots of bugs in lots of applications, and to people blaming us for changing things when such incorrect applications break, on the basis of all the requests we have received from users for a __MUSL__ macro. In every case, we have been able to recommend clean portable solutions that did not involve hard-coding assumptions about musl. The same issue was discussed in the thread on musl and gnulib compatibility last year, and we reached mutually acceptable conclusions: instead of adding __MUSL__ and documenting ways for gnulib to poke at stdio internals (which are documented by musl as being subject to change between versions and not acceptable for applications to poke at), we added functions like __freadahead etc. and gnulib is simply probing for their existence. Rich