Re: TOCTOU bug in make(1)

[Martin Husemann <martin%duskware.de@localhost>]

On Sun, Oct 09, 2022 at 11:02:58PM +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 would be shocked to find any (besides in gnu external code maybe).

The name of a function returning bool should be chosen to transfer the
proper sense of the return value. For predicates the sense could be
chosen arbitrarily, like:

	if (failed_to_send_p(status))
		error(....)

but for "action functions" this would be absurd, e.g.

	if (send_message(target, msg))
		error(....)

would be totaly obfuscated.

Side note: this is totaly different for arguments of type bool, where you
typically don't see the name of the formal parameter at the call site,
which is why I like the Qt style of a special enum for each "bool" arg
a lot (especially with newer C++ standards where the compiler flags passing
an enum value of the wrong enum type as an error).

Martin