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

[Xi Ruoyao <xry111@xry111.site>]

On Mon, 2023-07-10 at 15:46 -0400, Siddhesh Poyarekar wrote:
> On 2023-07-10 15:35, Xi Ruoyao wrote:
> > > Of course, I'm not concerned enough about these applications (sorry) to
> > > insist that it be put behind _FORTIFY_SOURCE, but I think it's a
> > > reasonable compromise.  That doesn't directly solve the analyzer problem
> > > though.  Maybe if it's OK to have the analyzer affect codegen, we could
> > > have the analyzer define _FORTIFY_SOURCE=3 and thus enable additional
> > > diagnostics too, like the __wur that also gets enabled only on
> > > fortification.  Is that something worth considering?
> > 
> > Or can we just guard the __nonnull usage against __GNUC_PREREQ (x, 0)
> > where x is 12 or 13?  In the recent GCC releases the optimizer won't
> > kill a side effect before an UB so it should be much safer (see my reply
> > to Zack), and it's unlikely they'll use the latest GCC for some legacy
> > broken code.
> 
> It depends on whether that's a deliberate design decision in gcc (and we 
> should probably look at what clang does too) or if it just happens to be 
> so today because of some IR layout coincidence.

Allow me trying to get some clarification...  Jeff has said

"I thought during the introduction of erroneous path isolation that we
concluded stores, calls and such had observable side effects that must
be preserved, even when we hit a block that leads to
__builtin_unreachable."

during the reviewing of some GCC patch.  So is the "must be preserved"
statement applies generally, or only for -fisolate-erroneous-paths-*?

> Then there are 
> compilers that pretend[1] to be gcc or clang but don't behave anything
> like them.
> 
> Thanks,
> Sid
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30621

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University