Re: Why require SLOW_BUT_NO_HACKS for stubs?

[John Spencer]

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.