[...]
> What /is/ the issue with the strict aliasing code? I was under the
> impression that it "merely" screwed up code that did icky things with
> pointers to members of unions. Comments made here about Linus' view on
> the thing sounds like it is some horrendous problem that may never get
> sorted. Which is the case?
The ANSI C standard prohibits accessing data through a pointer to a
different type. I.e., this is wrong:
int *pi = ...;
char *pc;
pc = (char *) pi;
*pi = 117; /* 1st */
*pc = 'a'; /* 2nd */
... *pi ... /* 3rd: Illegal */
Note that 3rd is illegal because we stored there through pc, an char * and
we are going to access it again at 3rd through a int *. It is fine (AFAIU)
if you store a char though pc and access it as a char later. The point is
that this is _hard_ (probably impossible in the general case) to detect for
a compiler, so the compiler is allowed to assume that *pi does not change,
since no accesses through an int * could have changed *pi. So it could
reorder stuff so that the setting at 2nd is done _after_ the line marked
3rd above...
> Looking at the EGCS/GCC manual section for strict-aliasing, is this the sort
> of `grunt work' that the unwashed multitude like myself could plow through
> and fix? How big a job is it? Is it even worth it?
I'd say it is a _big_ job. Plus you have to make sure not one slips
through. The main problem is that illegal accesses like above are used al
over the place, e.g. in memcpy() and its ilk to speed them up (so they work
with longs, not char by char). Mostly harmless, but the resulting kernels
on i586 don't boot because of code reordering of a memset() and setting a
struct member that tells the booting kernel to initialize IDE intefaces ;-)
In any case, I'd fix it where it can be done cleanly, and without loss of
efficiency. Some kind of solution from the GCC folks has to be forthcoming,
glibc has exactly the same kind of trouble with mem* functions. It might
take the form of _only_ builtin mem* functions, or a way to inhibit the
strict aliasing for a variable or function or file.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/