[patch v1] malloc: add malloc_zero_aborts tunable

[Wilco Dijkstra]

Hi DJ,

>Paul Eggert <eggert@cs.ucla.edu> writes:
>> On 2/12/26 11:15, DJ Delorie wrote:
>>> +  if (bytes == 0 && mp_.malloc_zero_aborts)
>>> +    abort();
>
>> This would cause malloc to fail to conform to the C standard, something 
>> that is far more likely to cause problems (even as an option) than to 
>> cure it. Nobody should use such an option.
>
> Agreed, but it's a tool for people who want to know if that part of the
> standard is affecting their code, and thus giving them a list of places
> to audit to make sure they're handling it correctly.

Interesting - I was thinking of something very similar. Basically I would add
a tunable that can be used for experimentation by malloc developers but
would NOT be recommended for general use. The tunable would support
multiple bits that control internal malloc settings.

I think aborting is a bit of a blunt hammer - don't we have a logging feature?
It would be interesting to be able to enable logging of malloc(0)/realloc(0)
calls just to see how frequently they occur. If that is possible inside a standard
distro then one could trivially log usage across a large set of applications and
usecases.

One could also return NULL for malloc (0) or return non-NULL for realloc (0) -
this would allow one to check that applications continue to work with different
allocators (something that aborting does not help with).

>> Also, it would slow down malloc.
>
> As I mentioned, I'd work on the tail recursion issue later.  The size
> would already be in a register (usually) and comparing it to zero is
> cheap enough, I'd add all the likelies etc.  I just had this thought and
> wanted to get feedback on it before I forgot it ;-)

Yes this seems more an RFC than a patch. It is possible to do it with no
overhead on non-zero sizes, and only a small overhead for the zero size
(which should be so rare that it doesn't matter).

Cheers,
Wilco