[PATCH v7] libio: Add nonnull attribute for most FILE * arguments in stdio.h

[Siddhesh Poyarekar]

On 2023-09-25 15:10, Zack Weinberg wrote:
> I still think this is a dangerous idea and, if we do it at all, we
> should do it *only* for compilers that have a *documented guarantee*
> that control flow paths that provably pass a NULL pointer to a __nonnull
> argument will *not* be treated as unreachable.  If I understood the

You're essentially asking the compiler to *define* a behaviour when 
faced with undefined behaviour, which doesn't seem like a reasonable 
request to me.  Likewise for glibc; we don't often go out of our way to 
specify an implementation defined behaviour when the standard specifies 
that behaviour as undefined.

> previous discussion correctly, GCC currently does not do that, but there
> is no documented guarantee that it will *never* do that, and nobody
> chimed in from LLVM's side.
> 
> (It's probably fine if compilers treat calls that pass a NULL pointer to
> a __nonnull argument as noreturn, or if they replace them with a trap
> instruction or a call to abort().  The danger I foresee is from any
> circumstance where NULL checks and side effects that happen *before* the
> bad call can get deleted.)

This (traps on undefined behaviour) was in fact discussed at the GNU 
Tools Cauldron last week as one of the things that the compiler could do 
for undefined behaviour in general, essentially subsuming sanitizers 
into the compiler proper.  One must realize though that (1) this would 
be 'best effort' on behalf of the compiler and (2) it's going to have 
overheads, albeit modern, speculating processors may subsume that 
overhead, which however is precisely where Spectre-like flaws operate...

Trying to make undefined behaviour safe in the compiler is not a bad 
idea at all, but guaranteeing fixes to application bugs in the compiler 
is a terrible idea IMO.

> (I think this policy should be applied to *all* instances of __nonnull
> in glibc's headers, not just new ones.)

You're asking for a change in position in glibc, which shouldn't block 
this current patch IMO, which aligns with the current position in glibc.

Thanks,
Sid