Date: Fri, 8 Jun 2012 12:51:34 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: printf POSIX compliance On Fri, Jun 08, 2012 at 05:46:10PM +0100, Reuben Thomas wrote: > On 8 June 2012 17:46, John Spencer <maillist-musl@...fooze.de> wrote: > > > > this is bogus, according to Rich: > > "all files are closed when a process terminates normally/calls exit. > > if you want to report write failures, just fflush(stdout) before exit and > > check the return value" > > Jim Meyering has an analysis of the problem here: > > http://www.gnu.org/ghm/2011/paris/#sec-2-1 Thanks; I'll take a look. > > gnulib is simply a huge pile of junk... > > Like the stdout problem, it's not that simple! gnulib has many > enthusiastic users, myself included, because it solves many > portability problems and adds much useful functionality. Thanks to > gnulib I was able to remove a total of about 1,000 lines of code from > GNU Zile. I have not heard a single complaint from users, so I guess > no-one tried to build it with musl. However, I have had success > stories from users building on far-out platforms like DOS, and I've > had far fewer bug reports on platforms I don't use since I started > using gnulib. I agree gnulib is very useful and successful for porting to obscure and broken platforms by making them outwardly resemble a POSIX-like platform. What I object to is the methodology of how replacements are selected and the pervasive use of undefined behavior and poking at implementation internals. To clarify, if there's a block of ugly not-possibly-portable code that's conditioned to only ever be compiled on known broken systems X, Y, and Z, it's unfortunate but probably non-problematic. But if this code is enabled on a possibly-infinite set of systems based on tests for certain behaviors, you end up invoking undefined behavior on systems for which you have not researched the results of that undefined behavior, and the result could range from just not building to serious security compromises. > So, please file bug reports rather than insults! I agree with this sentiment. That's why the quotation cited above was not filed; it was dug up from a past discussion of frustration with these kind of issues... > gnulib has receptive > and active maintainers, and we'll all benefit much more from fixed > software than from merely venting frustration. Agreed. > As regards the particular problem with freadahead, looking at the code > suggests a workaround of -DSLOW_BUT_NO_HACKS to avoid trying to build > the FILE-fiddling code. Someone building the package should not have to do this. The whole purpose of configure is to detect the needs of the system you're building for and get the build config right for you. The #error cases should be removed and replaced with code that works on ANY system, unless the relevant code will never be compiled at all except on a known finite set of old broken systems. 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.