[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aBoqXxp-RSCIh1Lf@voyager>
Date: Tue, 6 May 2025 17:27:27 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Sertonix <sertonix@...teo.net>
Subject: Re: putchar not returning EOF even though ferror is set
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
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.
