From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1173 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl bugs found through gnulib Date: Mon, 18 Jun 2012 10:55:45 -0400 Message-ID: <20120618145545.GC163@brightrain.aerifal.cx> References: <20120609230541.47eac2de@newbook> <4FD55156.7050302@cs.ucla.edu> <20120611182202.1ee4d019@newbook> <12545931.v3ALTEUUx8@linuix> <20120617235426.GX163@brightrain.aerifal.cx> <20120618082100.GT17860@port70.net> <4FDF26D8.6050309@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1340031601 21252 80.91.229.3 (18 Jun 2012 15:00:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2012 15:00:01 +0000 (UTC) Cc: Bruno Haible To: musl@lists.openwall.com Original-X-From: musl-return-1174-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 18 17:00:00 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SgdQt-0003Mz-KW for gllmg-musl@plane.gmane.org; Mon, 18 Jun 2012 16:59:59 +0200 Original-Received: (qmail 13799 invoked by uid 550); 18 Jun 2012 14:59:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13791 invoked from network); 18 Jun 2012 14:59:59 -0000 Content-Disposition: inline In-Reply-To: <4FDF26D8.6050309@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1173 Archived-At: 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 [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