mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: John Scott <jscott@posteo.net>
Subject: Re: [musl] fputs/fputc doesn't set errno on failure
Date: Thu, 8 Oct 2020 12:21:16 -0400	[thread overview]
Message-ID: <20201008162115.GZ17637@brightrain.aerifal.cx> (raw)
In-Reply-To: <20475045.GjpEljjT90@t450>

On Thu, Oct 08, 2020 at 10:55:47AM -0400, John Scott wrote:
> Hi,
> 
> I'm not subscribed, please keep me CC'd.
> 
> In this corner case, errno is unset despite fputs giving an error.
> I'm on Debian testing using musl-gcc 1.2.1.
> 
> #define _POSIX_C_SOURCE 200809L
> #include <assert.h>
> #include <errno.h>
> #include <stdio.h>
> int main(void) {
> 	FILE *f = fopen("/", "r");
> 	if(f == NULL) {
> 		perror("fopen()");
> 	}
> 	if(fputs("Hello world\n", f) == EOF) {
> 		assert(errno);
> 		perror("fputs()");
> 	}
> }
> 
> With glibc this prints EBADF for fputs.
> 
> The wiki page about writing tests [1], which I thought this would be
> a good candidate for, has the 404 link
> http://nsz.repo.hu/git/?p=libc-test
> 
> Please let me know if I can help debugging.
> 
> [1] https://wiki.musl-libc.org/writing-tests.html

The test is invoking undefined behavior by calling an output function
on a stream not opened for write or update mode. If you instead opened
"/" with O_RDONLY but then passed it to fdopen with mode "r+" or
similar, the POSIX-specified "shall fail" for "The file descriptor
underlying stream is not a valid file descriptor open for writing"
would apply and EBADF would be set (assuming fdopen didn't take the
liberty to fail here, which POSIX allows but does not require and musl
does not do since it would make fdopen more expensive).

Rich

  reply	other threads:[~2020-10-08 16:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 14:55 John Scott
2020-10-08 16:21 ` Rich Felker [this message]
2020-10-08 16:23 ` Markus Wichmann
2020-10-08 19:55   ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201008162115.GZ17637@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=jscott@posteo.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).