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

[Nikunj A Dadhania]

Thomas Huth <thuth at redhat.com> writes:

> On 08.08.2016 10:31, Segher Boessenkool wrote:
>> 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.
>
> Ouch, OK, I got it now. I'll send a new version of my patch...
>
>>> 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.
>
> That's a question for Nikunj who committed that change a couple of years
> ago ...
> (see http://git.qemu.org/?p=SLOF.git;a=commitdiff;h=7eca6a5e56f468)

I remember that we had a discussion on this and BenH had suggested that
we cannot re-audit all the code for correctness with strict-aliasing. So
disable it.

Regards,
Nikunj