Linux and aliasing?

David S. Miller davem@redhat.com
Sat Jun 5 11:09:00 GMT 1999


   From: mark@codesourcery.com
   Date: Sat, 05 Jun 1999 10:41:07 -0700

   Furthermoe, I bet that by now, if all this energy had been spent
   fixing the code in the kernel, you'd have made good headway on some
   of the most prominent data structures.  Yes, this will be a tedious
   chore, but it's an easy one: you enclose things in a union,
   compile, see what doesn't, fix it, and go on.

What seems to be ignored are the future maintenance costs incurred by
this set of changes to the kernel, as if "do it and get it over right
now" is some triviality.  Effort has been expended already to make
attempts to do this (mentioned here by Andi Klein who did a run at it
for the networking), and the findings made there support the
non-triviality claim, in Andi's case he tossed the work midstream due
to the non-stop overwhelming accumulation of issues.

Also some of the datastructures one would need to change are included
by userspace applications, especially for some of the networking
instances, and thus one would have ABI issues to concern themselves
about if they were to go and perform these transformations.  Much more
is it than a tedious chore.  One could certainly create another header
file, leave the old one alone with the same name, and use only the new
one inside the kernel, but does it make sense to have two copies and
maintain them?

However the headerfile interface issue is cleanly handled if only the
offending code in the kernel is changed (changes thus which are
invisible to the user headerfile ABI) to adhere to the proposed gcc
cast aliasing behavior.

This argument is orthogonal to your proposed possible future
maintenance costs gcc might incur due to the implementation of cast
aliasing behavior.

Later,
David S. Miller
davem@redhat.com



More information about the Gcc mailing list