bug#55895: [PATCH] maint: Fix ptr_align signature to silence -Wmaybe-uninitialized

[Anders Kaseorg]

Thanks for checking. I should have nailed down the reproduction recipe 
more precisely; sorry for that.  It seems the important step I should 
have included was CFLAGS=-O0.  Full recipe, using the same systems you 
checked:

Ubuntu 22.04 LTS x86-64
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
coreutils master, commit 93e099e4c3b659b2e329f655fbdc73fdf594a66e
./bootstrap --skip-po
./configure CFLAGS=-O0 (with or without --enable-gcc-warnings)
make

or

Fedora 36 x86-64
gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)
coreutils master, commit 93e099e4c3b659b2e329f655fbdc73fdf594a66e
./bootstrap --skip-po
./configure CFLAGS=-O0 (with or without --enable-gcc-warnings)
make -k

(With GCC 12.1.1 I get the same error and also additional errors that 
might merit further investigation.)

Can you reproduce with CFLAGS=-O0?

On 6/10/22 20:23, Paul Eggert wrote:
> On 6/10/22 15:24, Anders Kaseorg wrote:
> > ptr_align is always called with a pointer to uninitialized memory, so
> > it does not make sense for that pointer to be const.
>
> I don't see why not. ptr_align does not modify the referenced storage so 
> "void const *" is appropriate. If we changed the type to "void *" we'd 
> unnecessarily limit ptr_align's applicability.

My claim is that there’s never a reason to call ptr_align with a const 
pointer, because if the memory is initialized the pointer would have 
already been aligned, and if the memory is uninitialized you’re going to 
need to write to it somewhere.

Also, the current signature converts a const pointer to a mutable 
pointer.  Given the squishy nature of const in C (and the general lack 
of language features that would make it a more reliably useful signal), 
I know this kind of “safety hole” is so common that I hesitate to 
suggest it’s really a hole.  But given that it’s unnecessary we might as 
well avoid it.

GCC’s -Wmaybe-uninitialized seems to assume that a const pointer might 
be read, in the absense of better information from higher optimization 
levels.  Although this heuristic isn’t perfect (I’m not suggesting that 
the code is actually _wrong_), it seems reasonable enough to be worth 
appeasing, given that there doesn’t seem to be a notable downside.

Anders