There are a number of workarounds (casting macros etc.), but developing
these took its time, and for a variety of reasons these do not appeal to
linus (and other!). (One way would be to use memcpy for pointer casts, but
this will obviously clutter the code, unless you cna hide it in a nice
macro).
The biggest problem is, even with that macros, one has to actually go
in and change the kernel at many places, and identifying these is not a
matter of search&replace.
There is also the argument that a new macro might clutter code (well, not
my opinion ;)
> 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?
I don't think so.
> How big a job is it?
Who knows? The biggest problem is identifying it, and then the question
on how to actually solve this. Others have already given pointers to the
disucssion.
> Is it even worth it?
There are basically two position:
- "fix" the compiler. to the gcc people this is unacceptable, as it would
need to be a documented gcc extension, and had to be supported wlel into
the future (its different to the linux kernel where linus can just go
in and "break" things for good, as he has nearly total control over the
kernel use)
- "fix" the kernel to be work under the iso aliasing rules. please note
that neither gcc nor the kernel is broken, its just that the kernel is
not (and will never be) fully iso-c (a good thing no doubt ;). And which
and how it will interact with gcc (its primary compiler) will need to be
negotiated with many new features.
HTH,
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
-
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/