[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250505135613.GA1827@brightrain.aerifal.cx>
Date: Mon, 5 May 2025 09:56:13 -0400
From: Rich Felker <dalias@...c.org>
To: Sertonix <sertonix@...teo.net>
Cc: musl@...ts.openwall.com
Subject: Re: putchar not returning EOF even though ferror is set
On Mon, May 05, 2025 at 01:48:42PM +0000, Sertonix wrote:
>
> After a function using a FILE stream errors following calls of putchar
> (and probably other functions) don't return EOF. This can cause some
> busybox applets (like yes(1)) to never stop (when SIGPIPE is ignored in
> the environment).
>
> The commit message of e3cd6c5c265c (major stdio overhaul, using
> readv/writev, plus other changes) looks like this might have been
> intentional.
>
> Does musl consider this something which needs to be changed in busybox
> or would it be possible to change musl here?
>
> (If I read the glibc code correctly it checks ferror in some cases?)
>
> Ref https://gitlab.alpinelinux.org/alpine/aports/-/issues/17129
There is no specification anywhere in C or POSIX (the latter wouldn't
really matter since POSIX is aligned with C and can't make
requirements contradictory to it, but checking can be informative
anyway) that the error indicator being set for a stream causes further
writes to fail. glibc doing that appears to just be something they...
made up?
This is in contrast to the EOF status for read operations, which is
required to be "sticky" and cause future read attempts to return EOF.
Applications that want to stop when an error has been encountered
should check the return value of the writing function or check
ferror().
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.
