[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Alejandro Colomar]

Hi Paul,

On Fri, Oct 25, 2024 at 04:30:09PM GMT, Paul Eggert wrote:
> On 2024-10-25 15:58, Alejandro Colomar wrote:
> > The purpose of the change was
> > to prevent vulnerabilities, not to promote the use of null pointers as
> > 0-sized objects.
> 
> Not sure I agree about the purpose. Lots of GNU code has used null pointers
> as zero-sized objects for years. It's a natural consequence of starting off
> a (pointer,size) pair as both zero, and it's been documented as a Gnulib
> assumption since 2003 (code assumed it even before that).

I think it's fine if projects opt-in to this, but other projects might
want to continue with NULL meaning an invalid pointer, and enforce
strong diagnostics when a null pointer arrives at a place where it
shouldn't.  If you have diagnostics, you can turn them off at your will.
However, if they're not there, a user cannot add them.

> If compilers start warning about this sort of thing we'll shut off the
> warnings. It wouldn't be the first time compilers chattered
> counterproductively.

I'm not suggesting adding new warnings.  Only not removing the existing
ones.

Or maybe you refer to the addition of _Optional or something like that?
If it's that, that's still in very early stages, and I'm not in favor
not against it.  But I'm curious about it, and think that it might end
up with entire classes of bugs.  So, I'm open to seeing it in some
experimental patches to test it.  Having something like const
correctness but about null is an interesting idea.

But yeah, I don't intend to add diagnostics to existing code.  Agree.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241026/9bd3be51/attachment.sig>