[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
