Re: stdioext on musl

[Rich Felker]

On Sun, Jun 17, 2012 at 04:10:52PM -0700, Paul Eggert wrote:
> On 06/17/2012 03:53 PM, Rich Felker wrote:
> > By "better interfaces" do you mean the
> > 4 already-mentioned stdio extension functions, or something else?
> 
> Yes, I mean the functions that Bruno mentioned.
> 
> > I mean will it find them without needing a special macro like
> > __MUSL__?
> 
> Having a symbol like __MUSL__ helps simplify gnulib's job, because
> it needn't bother to use a heuristic like "if it has __stdio_read and
> __stdio_write, it must be musl", but can simply use __MUSL__ directly.

This heuristic is wrong. So is checking for musl. The correct check is
to test for the _behavior_ you need and use the results of those
tests. This is the most basic principle of autoconf.

> If musl doesn't want to define __MUSL__, that's OK, gnulib can just
> define __MUSL__ on its own using that heuristic, as in Bruno's patch.

Nope, __MUSL__ is in the namespace reserved for the implementation. In
particular, adding #ifdef __MUSL__ #error to any of the standard
headers is valid, and it's what one of our users just suggested we do
if this patch to gnulib is done as-is...

It would be valid to define something in the application-reserved
namespace, but there is no reliable test by which to determine whether
to define it. __stdio_read is NOT public.

> If the heuristic goes wrong in some future platform, we'll fix it.
> This is normal; it's no big deal.  That being said, it's nicer for
> gnulib if musl announced its presence with a symbol like __MUSL__.

It's nicer if gnulib plays by the same rules as everybody else rather
than considering itself above the rules.

Up until Bruno jumped in (when I was communicating mainly with Eric),
I was pleasantly surprised at how sane and reasonable the discussion
was. It completely defied the reputation gnulib has, and folks seemed
genuinely interested in working with us and addressing the systemic
non-portability problems of gnulib -- stuff like fixing all the
fallback cases and removing the need for -DSLOW_BUT_NO_HACKS, etc.

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.

I would really like to see gnulib modernize. I would like to see it
work out-of-the-box, even if somewhat slowly, on ANY not-yet-invented
system that satisfies the standard interface contracts. However gnulib
is not my project, and it's not my business to tell you that you must
do these things if you're horribly opposed to 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, the only
option I'm left with is to keep publicly expressing frustration with
how broken gnulib is. It's not the option I like, because I'm really
sick of dealing with apps breaking because of gnulib already. I'd like
to have a nice clean solution like we discussed with Eric last week,
so I can get on to better things and not worry that compiling gnulib
software is going to start breaking again -- or worse yet, that
binaries using gnulib are going to stop working.

Rich