RFH: aliasing problems

[Sergei Organov]

Steven Johnson writes:
[...]
> Here is concrete help:
>
> if_ethersubr.c
>
> Line 598, 692
> sin = (struct sockaddr_in *)&(ifr->ifr_addr);
>
> change it to
> sin = (struct sockaddr_in *)(void*)&(ifr->ifr_addr);
>
> Line 881:
> sa = (struct sockaddr *) & ifr->ifr_data;
> to
> sa = (struct sockaddr *)(void*) & ifr->ifr_data;
>
> Why, because C99 says you can turn any pointer to a void* and any void* 
> to any other pointer.  This will silence the warning.

That's exactly what one should never do. Silence compiler warnings by
yet another trick will bite us later. Aliasing rules start to play when
you *access* actual object by dereferencing the pointer, so any
intermediate pointer conversions don't change anything.

After your "fix", you continue to access the object, say, ifr->ifr_data,
through incompatible pointer of type "struct sockaddr*". To fix this,
you either need to change type of ifr->ifr_data, or type of the pointer
you access the object by. Converting pointers back and forth doesn't
change anything but make poor compiler crazy to the level it stops warn
you where it should.

> In this case there is no possibility for common sub expression
> elimination as there is no manipulation of pointer data between the
> setting of this value and its use that could trigger the optimisation,
> and it be working from a previous state, and not a undetected updated
> state, and so the warning is completely bogus.

What common sub-expression elimination has to do with aliasing rules?
The answer is: nothing.

Steven, it seems you still miss the meaning of aliasing rules, so all the
suggestions you give are just tricks to silence compiler warnings, not
actual fixes to the problems.

-- Sergei.