Date: Tue, 18 Jun 2013 14:42:24 -0400 From: Rich Felker <dalias@...ifal.cx> To: Paul Eggert <eggert@...ucla.edu> Cc: Eric Blake <eblake@...hat.com>, musl@...ts.openwall.com, bug-gnulib@....org Subject: Re: gnulib cross-compiling issue with musl 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
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.