Re: [PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes

[Jakub Jelinek <jakub@redhat.com>]

On Tue, Dec 19, 2023 at 08:11:11AM +0100, Martin Uecker wrote:
> Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek:
> > Hi!
> > 
> > The following patch changes -Walloc-size warning to no longer warn
> > about int *p = calloc (1, sizeof (int));, because as discussed earlier,
> > the size is IMNSHO sufficient in that case, for alloc_size with 2
> > arguments warns if the product of the 2 arguments is insufficiently small.
> > 
> > Also, it warns also for explicit casts of malloc/calloc etc. calls
> > rather than just implicit, so not just
> >   int *p = malloc (1);
> > but also
> >   int *p = (int *) malloc (1);
> > 
> > It also fixes some ICEs where the code didn't verify the alloc_size
> > arguments properly (Walloc-size-5.c testcase ICEs with vanilla trunk).
> > 
> > And lastly, it introduces a coding style warning, -Wcalloc-transposed-args
> > to warn for calloc (sizeof (struct S), 1) and similar calls (regardless
> > of what they are cast to, warning whenever first argument is sizeof and
> > the second is not).
> 
> I would generally see function arguments that are swapped relative
> to the documented ABI as more than a coding style issue even in 
> cases where it can be expected to make no difference.

If you have suggestions how to reword the documentation, would that be
sufficient for you?  I still don't see why given correct alignment one can't
store struct S into sizeof (struct S) sized heap char array, but if the
documentation explain reasons why should one write it one way and not the
other except for coding style, sure.

> > Ok for trunk if this passes bootstrap/regtest?
> 
> I wonder whether we could turn on -Walloc-size for -Wall with this change?

I think that is a possibility, yes.

BTW, the patch passed bootstrap/regtest on x86_64-linux and i686-linux.

	Jakub