Re: TOCTOU bug in make(1)

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Sun, Oct 09, 2022 at 23:02:58 +0200, Roland Illig wrote:

> Am 07.10.2022 um 00:28 schrieb David Holland:
> > On Fri, Oct 07, 2022 at 12:46:06AM +0300, Valery Ushakov wrote:
> >   > It also, unnecessarily, IMHO, decided to change the return type to
> >   > a more "modern" bool thus further obscuring the fact that the
> >   > function was a simple wrapper around unlink(2).
> > 
> > Can we revert that? Using bool for success/failure is ambiguous (does
> > true mean it succeeded or failed? both are reasonable) whereas 0/-1 or
> > zero/nonzero is a clearly established and well understood idiom.
> 
> Can you show me a function in the NetBSD source tree that has return
> type 'bool' (not 'int') and returns 'true' to indicate failure?
> 
> I searched for '^\.Tf bool$' and found several functions that return
> 'false' to indicate failure but none that returned 'true' to indicate
> failure.

The convention to return 0 from syscalls to indicate success is 50+
years old and this function is a wrapper around a syscall.  It sets
errno on failure for the specific case it was created for, lie a
syscall would do.  It looks like a syscall, walks like a syscall, ...
By your own admission you didn't understand the purpose of this
wrapper, deleted the comment that explained that purpose (even if it
could have been more explicit - but then that comment assumed that
unlink(2) vs directories is something people are aware of I guess).
Please, can we restore the calling convention and the comment and be
done with it?  I don't see much sense in bike-shedding the relative
merits of using "bool" as return type in a context where a very well
established idiom exists.

-uwe