|
Message-ID: <87o7bjttcn.fsf@oldenburg.str.redhat.com> Date: Tue, 12 Mar 2024 15:31:04 +0100 From: Florian Weimer <fweimer@...hat.com> To: "Zack Weinberg" <zack@...folio.org> Cc: "Gabriel Ravier" <gabravier@...il.com>, "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 * Zack Weinberg: > 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 don't think the VFS close action is subject to reference counting. Otherwise the current coreutils error checking wouldn't work because in many cases, another process retains a reference to the OFD. Thanks, Florian
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.