[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Sam James]

Alejandro Colomar <alx@kernel.org> writes:

> Hi Joseph,
>
> On Fri, Oct 25, 2024 at 10:41:52PM GMT, Joseph Myers wrote:
>> On Fri, 25 Oct 2024, Alejandro Colomar wrote:
>> 
>> > nullability much worse (FWIW, I think all diagnostics should remain
>> > enabled in C2y; otherwise, we'd be introducing other vulnerabilities,
>> > which is what the change tried to avoid in the first place).
>> 
>> Passing something that is explicitly NULL (or can be seen by static 
>> analysis to be a null pointer) is suspect and still appropriate to warn 
>> about, yes (the functions do nothing with NULL input and zero size, so if 
>> the argument is always null it's questionable why the call is in the 
>> source code at all).  The useful case for that C2y change is definitely 
>> the one where the size and pointer are only known at runtime, but if the 
>> size is 0 then the pointer might be null.
>
> But, if something like _Optional is added to C2y in the future, or if
> Clang's _Nullable is supported at some point by a static analyzer, then
> you can diagnose run-time null pointers.  I'm worried that C2y's change
> in the semantics of null pointers might reduce the number of such
> diagnostics (if you for example mark memcpy(3) as accepting pointers to
> _Optional data).  This is why I strongly opposed to the acceptance of
> that paper for now.  I think it wouldn't have hurt to wait until the
> full picture was clearer.  (ABIs already guarantee that pointer
> arithmetic on run-time null pointers are valid.)
>
> Or for example if you'd remove the [[gnu::nonnull]] attribute from those
> functions (as is being discussed at the moment in another thread),
> although that doesn't warn much (except maybe via -fanalyzer), so I'm
> not sure about it.  FWIW, I'd say that whatever you do with memcpy(3) et
> al., please don't reduce any single existing diagnostic, neither for
> compile-time nor run-time null pointers.  The purpose of the change was
> to prevent vulnerabilities, not to promote the use of null pointers as
> 0-sized objects.

I don't think this is quite right. The paper spends some time talking
about how it is a more natural way to write various algorithms (which I
agree with and it's why it's bothered me for a long time).