[musl] putchar not returning EOF even though ferror is set

[musl] putchar not returning EOF even though ferror is set

[Sertonix]

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

Re: [musl] putchar not returning EOF even though ferror is set

[Rich Felker]

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

Re: [musl] putchar not returning EOF even though ferror is set

[Markus Wichmann]

Am Mon, May 05, 2025 at 01:48:42PM +0000 schrieb Sertonix:
> 
> 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

If it is any consolation: As long as the block size is coprime to one
more than the string length, at some point the application should stop
(because that means that at some point the putchar('\n') will be called
when the buffer is full). But of course, the main case is that the
string is just "y", so the full output is 2 bytes, and that isn't
coprime to 1024.

The glibc behavior here is not conforming. No C standard I could find
specifies it or allows it explicitly. They all say that fputc() writes
the character given to the file, not that it may or may not do so
depending on the whims of the implementor. busybox should change its yes
applett to either test the return values of all the stdio function
called, or else test ferror() as an additional loop exit condition. Or
possibly even in place of the current one (which is that putchar('\n')
returns EOF).

Ciao,
Markus