Am Dienstag, dem 19.12.2023 um 09:47 +0100 schrieb Jakub Jelinek: > 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?
Maybe simple remove "This is a coding style warning." ? > 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. I do not think we need to argue one way or the other in the documentation. > > > > 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 Anyway, thank you for fixing / improving this warning! Martin
