[SLOF] [PATCH] Fix remaining compiler warnings in sloffs.c

Segher Boessenkool segher at kernel.crashing.org
Mon Aug 8 18:31:06 AEST 2016


On Mon, Aug 08, 2016 at 08:38:33AM +0200, Thomas Huth wrote:
> On 08.08.2016 03:30, Segher Boessenkool wrote:
> > On Fri, Aug 05, 2016 at 10:48:18AM +0200, Adrian Reber wrote:
> >>> +static void print_header_date(void *dptr)
> >>> +{
> >>> +	uint8_t *date = dptr;
> >>> +
> >>> +	if (*(uint64_t *)dptr != 0) {
> > 
> > This is the exact same problem though.  Should be something like
> > 
> > 	if (date[0] || date[1] || date[2] || date[3]
> > 	    || date[4] || date[5] || date[6] || date[7])
> 
> I'm now type-punning dptr here, not date, so this time it's a void
> pointer instead of a char array ... and I thought type-punning a void
> pointer would be OK since they are considered to alias any other kind of
> data? I might be wrong here, though, these aliasing problems always
> cause a headache for me.

That is not how it works.  The pointer type does not matter; it is
perfectly legal to cast a pointer.  What is not okay is accessing
something with a type not compatible with its effective type (ignoring
signedness), unless the access is character type.  "Effective type"
usually is just the declared type of the datum.

> In the end, we just might want to add -fno-strict-aliasing to the
> HOSTCFLAGS, just like we already did it in make.rules for the normal
> CFLAGS, and call it a day.

Or you could fix the problems.  SLOF used to work with -fstrict-aliasing,
and it was a nice performance win.


Segher


More information about the SLOF mailing list