[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why require SLOW_BUT_NO_HACKS for stubs?
From: |
John Spencer |
Subject: |
Re: Why require SLOW_BUT_NO_HACKS for stubs? |
Date: |
Mon, 25 Jun 2012 00:42:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Mail/1.0 |
On Sun, 24 Jun 2012 04:05:39 -0700, Bruno Haible wrote:
Paolo Bonzini wrote:
> >> > The test as it stands is "error out on unsupported platforms unless
> >> > user specifies to use slow method".
> >> > My proposal is "On unsupported platforms, use the slow method instead
> >> > of erroring out."
> >
> > If we did this, nobody would report to bug-gnulib (or to the libc
> > maintainer)
> > the need to port the functions. You would get a slow or buggy program
> > instead.
>
> You can add a test program that detects an unported-to libc. So they
> would get a slow program but also a make check failure.
Unfortunately, a majority of the users (between 50% and 90%, I got the
impression) runs "make; make install" without "make check". And many of
them would also ignore a #warning. To catch the attention of the users
and let them get in touch with us for porting the code, one really has
to provoke a build failure.
better said, catch the HATE of users.
anything is better than a failed build.
nobody cares if single cornercases are slow, as long as the program works.
and if they care, *THEN* they can get in touch with you to improve a
slightly unoptimal situation, as opposed to a *catastrophic* situation.
even if they know C and autoconf good enough to find the cause of their
build failure, and english good enough to contact this list, they
probably don't have much interest to discuss with you guys for days
until they finally get a gnulib fix upstream (which will be in their
software of choice months or years later) or not, unless they know how
to apply patches manually.
you seem to be one of very few who thinks it's good to create trouble
for other people.
in the case of musl, dozens of people ran into the compile error in the
last 2 years, wasted cumulative days or weeks of work to fix it (more
than once, for every packages that uses another version of gnulib) and
to retry hour-long compiles that broke in the middle.
but apparently nobody seemed to bother to come here and discuss the
issue (or he was simply ignored).
instead they came to the musl irc channel to complain.
so your approach is provably ineffective (and very arrogant).
Now go ahead and enable the portable fallback code, and add 100 lines of
warnings to it so that *it will* get noticed, and if the users care
about 1% faster speed when they use printf, they will come anyway.
let's finally put an end to this sadistic farce.
- Why require SLOW_BUT_NO_HACKS for stubs?, Isaac Dunham, 2012/06/10
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paul Eggert, 2012/06/10
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Isaac Dunham, 2012/06/11
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paolo Bonzini, 2012/06/12
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, John Spencer, 2012/06/12
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Bruno Haible, 2012/06/17
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paolo Bonzini, 2012/06/23
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Bruno Haible, 2012/06/24
- Re: Why require SLOW_BUT_NO_HACKS for stubs?,
John Spencer <=
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Paul Eggert, 2012/06/25
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, John Spencer, 2012/06/25
- Re: Why require SLOW_BUT_NO_HACKS for stubs?, Philipp Thomas, 2012/06/25
- Re: musl bugs found through gnulib, Bruno Haible, 2012/06/17
- Re: [musl] Re: musl bugs found through gnulib, idunham, 2012/06/17
- Re: [musl] Re: musl bugs found through gnulib, Rich Felker, 2012/06/18
- Re: [musl] Re: musl bugs found through gnulib, Eric Blake, 2012/06/18
- Re: [musl] Re: musl bugs found through gnulib, Rich Felker, 2012/06/18
- Re: musl, fdopen test, Bruno Haible, 2012/06/19
- Re: musl, fdopen test, Jim Meyering, 2012/06/19