musl - Re: Re: Tweaking the program name for <err.h> functions

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.