Re: patch adding a pidfile-option to script(1)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 16 Sep 2026 23:18:26 -0400 (EDT)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> >>> This patch can be made safe with a much smaller modification:
> >>> simply keep SIGUSR1 blocked _except_ during the calls to read() and
> >>> write() in dooutput(), when there is no risk of interrupting access
> >>> to the stdio data structures.
> >> That makes it safe...for one particular implementation.  It is not
> >> safe in general.  There is no promise that stdio is signal-unsafe
> >> only when the signal interrupts a stdio call, though that is the way
> >> most implementations happen to work.
> 
> > No, it is safe in general for all POSIX-conformant systems:
> 
> >    [...]
> 
> Yes and no.
> 
> That particular change - blocking the signal except during
> read()/write() - is safe.  But the "when there is no risk of
> interrupting access to the stdio data structures" is misleading; while
> it is mostly about that under NetBSD, to be safe in theory you have to
> guard against all signal-unsafe functions, not just those that poke at
> stdio data structures.  (And, indeed, if the call done in the signal
> handler is one that can cause stdio to malloc, even in practice you
> have to guard against interrupting malloc-family calls too even though
> they have nothing to do with stdio's data structures.)

You are technically correct that -- depending on the definition of
`the stdio data structures' -- the informal explanation I gave might
not be perfectly sufficient to justify the safety of the specific
change I suggested.

And that rephrasing the explanation as `when there is no risk of
interrupting any function that is not formally marked as
async-signal-safe in IEEE Std. 1003.1-2024, Volume XSH: System
Interfaces, Sec. 2.4.3 ``Signal Actions'' ' instead would justify the
safety of the specific change I suggested.

(Meanwhile the rest of the change turns out to be troublesome for
other reasons because the file is open in two separate processes, so I
don't think this subthread needs any further litigation!)