[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120618145545.GC163@brightrain.aerifal.cx>
Date: Mon, 18 Jun 2012 10:55:45 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Cc: Bruno Haible <bruno@...sp.org>
Subject: Re: Re: musl bugs found through gnulib
On Mon, Jun 18, 2012 at 03:02:16PM +0200, John Spencer wrote:
> On 06/18/2012 10:21 AM, Szabolcs Nagy wrote:
> >* Rich Felker<dalias@...ifal.cx> [2012-06-17 19:54:26 -0400]:
> >
> >>On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
> >>>Replacements of *printf, because of
> >>> checking whether printf supports infinite 'long double' arguments... no
> >>I'm just going to change isnanl to handle the invalid bit patterns
> >>because I'm sick of this issue...
> >>
> please don't do this. this would be a win of Evil against Good.
>
> do you see were this goes ?
> first they wanted you to implement __freadahead, now they want 4
> such functions
Actually at first they were trying to do it in gnulib, and I told them
rather than trying to put ugly musl-specific hacks in gnulib that will
break in the future, I'd prefer to just provide the function, as long
as it can be detected by configure and not...
> plus a broken __MUSL__ macro.
This is rejected.
Bruno has criticized my rejection of it as purely theoretical,
ignoring practical needs, etc. But you've seen it on the list and irc:
how many times have new users/contributors shown up trying to get a
package working with musl, asked if there's __MUSL__ or similar, and
then LEARNED SOMETHING and FIXED THE PACKAGE RIGHT when told that
there's no such thing and that the package's configure script should
be fixed to detect things rather than hard-coding assumptions?
I hate to think how many packages would have broken #ifdef __MUSL__
patches in them by now if the people submitting patches had that
available to work with...and then the package maintainers would get
frustrated with musl in a hurry when they had to fix things again
later because the assumption they hard-coded was bad.
> this is usually refered to using the proverb "give them the small
> finger and they take the entire hand".
I do feel a bit like my interaction with Eric versus later interaction
with Bruce has been something of a bait-and-switch. But you know the
old saying: never attribute to malice what can be adequately
explained....
> the tactics of the gnulib folks is to wear you down, until they have
> no work to do at all.
I don't follow your reasoning here. If anything Bruno has been
pushing to make more work for himself by adding more special cases
that have to be maintained, instead of adopting a general solution..
> also note how Bruno changed the subjects in "gnulib portability
> issues" thread on the gnulib ML into something that suggests the
> opposite, i.e. that musl is broken.
>
> there's only one broken program out there, which is gnu coreutils' "od".
> if someone wants to use coreutils and cares about this uncommon
> issue, he/she can simply use a patch for this specific program.
The problem is that gnulib is potentially replacing printf in many
programs (I haven't checked this; would you care to check?) over this
stupid issue that only affects one broken program, resulting in
massive bloat for users, and potentially breaking things.
> >i think we should not invest too much time
> >into gnulib but work on a proper libc
> >testsuit instead..
>
> full ACK. now that we know which tests are responsible for detecting
I think nsz was talking about testing, not about app compatibility.
The gnulib tests have turned out to be 50-50 or worse for detecting
actual bugs versus broken tests. Off-hand, that's slightly worse than
Open POSIX Test Suite's rate...
In any case, I think we've gotten almost all we can out of the gnulib
tests in terms of fixing bugs.
> many musl functions (wrongly) as broken, we can simply create some
> "gnulib-fix" program that makes these tests always succeed, thus
> keeping their bloat outside.
If you'd like to post a script to do this that actually works with all
gnulib programs, I'll consider that as an alternative to working with
the gnulib developers... ;-)
> PLUS add a warning at a prominent spot that programs using GNULIB
> should be built statically to avoid future incompatibilities due to
> their illegal poking at internals.
I don't think there's any poking at internals yet, and the proposal is
NOT to include any of that stuff.
> sabotage currently uses the following approach to beat gnulib into
> functioning:
>
> empty_file() {
> rm -f "$1"
> touch "$1"
> }
>
> ../configure -C --prefix=/ || exit 1
>
> #fixing gnulib
>
> cd lib
> for i in printf.c fprintf.c freadahead.c closein.c fseterr.c vfprintf.c ; do
> empty_file "$i"
> done
>
> echo "#define __printf__ printf" >> config.h
> echo "#define rpl_fprintf fprintf" >> config.h
>
> cd ..
This looks like ugly hackery that's poking at gnulib internals rather
than operating at the configure level like it should. I think it's a
bit hypocritical to criticize them for poking at libc internals and
then turn around and poke at their internals...
> sed -i 's,atexit (close_stdin),,' gzip.c
> # probably better to just echo "void close_stdin(void) {}" > close_in.c
This will make some of the GNU coreutils non-conformant to POSIX.
I've already discussed on this list why using an atexit function for
closing stdin or stdout is the heart of the problem and the source of
all the complexity. If the main program just closed the stream at the
natural point in the normal program flow, it would be trivial to do
correctly and portably.
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.
