Re: [PATCH] Revert "libio: Add __nonnull for FILE * arguments of fclose and freopen"

[Florian Weimer <fweimer@redhat.com>]

* Florian Weimer:

> * Siddhesh Poyarekar:
>
>> On 2023-07-10 18:07, Xi Ruoyao wrote:
>>> This reverts commit 71d9e0fe766a3c22a730995b9d024960970670af.
>>> Apparantly the maintainers do not like __nonnull.  And I'm too
>>> pissed
>>> off to work on this anymore.  Anyway I don't care about the analyzer so
>>> they can just add these as ugly special analyzer patterns.  And I'm not
>>> so stupid to pass NULL to these things myself, so lacking a warning is
>>> not a problem to me.
>>
>> Sorry you feel this way, but this is still unresolved as we don't have
>> a consensus yet.  However I understand if you're frustrated and don't
>> want to work on this for now; I do hope you return though.
>>
>> In any case, if the consensus does steer towards never using
>> __nonnull__, it'll likely be better to do it by hacking cdefs.h to
>> expand __nonnull to nothing.
>
> We can do this under #ifdef _LIBC.  This way, analyzers can still
> benefit from the annotations, but the attribute does not affect the
> glibc build.
>
> It doesn't make sense to maintain the nonnull-ness of glibc function
> arguments outside glibc, so we should add these annotations to the
> installed headers.

While trying to implement that, I found this in include/sys/cdefs.h:

/* The compiler will optimize based on the knowledge the parameter is
   not NULL.  This will omit tests.  A robust implementation cannot allow
   this so when compiling glibc itself we ignore this attribute.  */
# undef __nonnull
# define __nonnull(params)

So the whole thing is really a non-issue, and I don't think we need to
revert anything.

We can stop doing that #undef dance if there's an -f flag to get the GCC
behavior we want, so that we benefit from GCC diagnostics during the
glibc build.

Thanks,
Florian