> and blame gcc developers for breaking it, or stay in the unsafe ground
> and fix kernel each time gcc will introduce new nasty optimizations.
> This may become tricky later - for instance as making kernel codebase
> -fstrict-aliasing ready.
Until the C language improves its ability to describe aliasing safety I
don't think its going to be practical to fix the issue. I've seen patches to
make slhc.c strict aliasing safe for example, and they are too ugly to live
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:29 EST