[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <84bf19d7-c2ba-46e7-a77d-ecc6497f08a1@app.fastmail.com>
Date: Tue, 12 Mar 2024 10:21:19 -0400
From: "Zack Weinberg" <zack@...folio.org>
To: "Florian Weimer" <fweimer@...hat.com>,
"Gabriel Ravier" <gabravier@...il.com>
Cc: "Rich Felker" <dalias@...c.org>,
"Skyler Ferrante (RIT Student)" <sjf5462@....edu>, musl@...ts.openwall.com,
"Andreas Schwab" <schwab@...e.de>, "Alejandro Colomar" <alx@...nel.org>,
"Thorsten Glaser" <tg@...bsd.de>, NRK <nrk@...root.org>,
"Guillem Jover" <guillem@...rons.org>,
"GNU libc development" <libc-alpha@...rceware.org>,
libbsd@...ts.freedesktop.org, "Serge E. Hallyn" <serge@...lyn.com>,
"Iker Pedrosa" <ipedrosa@...hat.com>,
"Christian Brauner" <christian@...uner.io>
Subject: Re: Re: Tweaking the program name for <err.h> functions
On Tue, Mar 12, 2024, at 9:54 AM, Florian Weimer wrote:
>> Doing this would break many programs, such as:
>> - most of coreutils, e.g. programs like ls, cat or head, since they
>> always `close` their input and output descriptors (when they've
>> written or read something) to make sure to diagnose all errors
>
> A slightly better way to do this is to do fflush (stdout) followed by
> error checking on close (dup (fileno (stdout))).
Does that actually report delayed write errors? As you have it,
the close() just drops the fd created by the dup(), the OFD is
still referenced by fd 1 and therefore remains open. I would
expect scrupulously correct and thread-safe code for detecting
write errors on stdout without fd 1 ever becoming invalid to
look something like this:
int stub_stdout = open("/dev/null", O_WRONLY|O_CLOEXEC);
if (stub_stdout < 0)
perror_exit("/dev/null");
flockfile(stdout);
if (ferror(stdout) || fflush(stdout))
perror_exit("stdout: write error");
int original_stdout = fcntl(fileno(stdout), F_DUPFD_CLOEXEC, 3);
if (original_stdout < 0)
perror_exit("dup(stdout)"); // e.g. ENFILE
dup2(stub_stdout, fileno(stdout)); // failure here should be impossible
close(stub_stdout); // ditto
funlockfile(stdout);
if (close(original_stdout) < 0)
perror_exit("stdout: write error");
... Which is enough of a pain in the neck that I can't blame people
for wanting to just do close(1), especially during process termination.
(I thought Linux had a "swap these two fds" mode for dup3(), which would
simplify the above a bunch and get rid of one of the two places where you
can hit the file descriptor limit, but it's not mentioned in my copy of
the manpage. Did I just dream it?)
zw
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.
