Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed()
Le Fri, 22 Jan 2021 23:45:45 +0100,
Florian Weimer <fw@deneb.enyo.de> a écrit :
Hello.
Sorry for the delay, I completely forgot about this issue.
> * Bérenger:
...
> Why do you think this is a bug?
POSIX 10031-2017 standard says:
> RETURN VALUE
Upon successful completion, the dprintf( ), fprintf( ), and printf( )
functions shall return the number of bytes transmitted.
Upon successful completion, the sprintf( ) function shall return the
number of bytes written to s, excluding the terminating null byte.
>
Upon successful completion, the snprintf( ) function shall return the
number of bytes that would be written to s had n been sufficiently
large excluding the terminating null byte.
>
If the value of n is zero on a call to snprintf( ), nothing shall be
written, the number of bytes that would have been written had n been
sufficiently large excluding the terminating null shall be returned,
and s may be a null pointer.
I changed my code so that it stores printf's result. It does not
contains 0, which is the real number of bytes transmitted (none were),
but the number of bytes it should have transmitted.
In the error section, we can read that it can return the same errors
(in errno) as fputc, which itself says, as for errors:
> [EBADF] The file descriptor underlying stream is not a valid file
> descriptor open for writing.
This is clearly the case here. The underlying file descriptor *is*
closed. Thus, fputc (thus fprintf) functions should return -1 and have
errno set at EBADF.
I do not have access to older versions of POSIX nor to C standard.
According to wikipedia, "Debian 10 (Buster) was released on 6 July
2019;" which is at least 1 year after the POSIX standard I put a
reference to was out.
I must confess I didn't checked the POSIX standard on this question
before writting this answer, because the manpage clearly states that
"Upon successful return, these functions return the number of
characters printed" which is not the case here.
I do note that the manpage does not mentions errors returned nor being
conform to POSIX-2017: it says:
> CONFORMING TO
fprintf(), printf(), sprintf(), vprintf(), vfprintf(),
vsprintf(): POSIX.1-2001, POSIX.1-2008, C89, C99.
>
snprintf(), vsnprintf(): POSIX.1-2001, POSIX.1-2008, C99.
With those informations, I really think this is a glibc bug (not
present in muslc since it do returns -1 and sets errno at -9, which is
the defined value of EBADF).
PS: sorry for putting you in "To" field, Florian Weimer, did a "reply",
instead of "reply to all"
Reply to: