Rich,
> Then Bruno came back to us with this monstrosity of a patch that
> insists, for no good reason, on trying to detect musl specifically,
> thereby increasing the amount of broken special-cased non-portable
> code in gnulib rather than modernizing it.
> ...
> What is my business is that Bruno wants to start poking at internals
> of musl in a way that WILL BREAK in nearly every single application
> that's using gnulib, and that will have users coming to us with bug
> reports when gnulib is the code at fault. I can't and won't work with
> that. If it's your final decision to do things that way ...
There is a big misunderstanding here. I don't want to commit that large
patch with lots of "#ifdef __MUSL__" if there will soon be a better way
to do, after some changes have gone into musl.
The purpose of the patch was
1. to get down from the "gnulib is unportable" discussion, and provide
a patch that provides the interoperability today,
2. give you some hints about which kinds of primitives in musl would
be needed for gnulib to get rid of these "#ifdef __MUSL__".
I am writing to you precisely to make the plan that Eric outlined more
concrete.
I have told you constructively what our needs are:
1) a macro like __MUSL__
2) the 4 functions __freadahead, __freadptr, __freadptrinc, __fseterr.
Now it's your turn. Please consider implementing these needs or parts of
these needs in musl. (Even if you don't agree that these are or should
be needs of gnulib. Just believe me and Paul that we need this.)
Then I, on the gnulib side, will see to which extent the (admittedly large)
patch can be reduced to something more reasonable.
Once again: My goal here is to support all the stdioext functions on future
versions of musl, with as little #ifdef as possible. The result depends on
what will go into <http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl>.
Bruno
