Re: type based aliasing again

[Marc Espie <espie AT quatramaran.ens.fr>]

In article < 19990915020836.M3983@cerebro.laendle > you write:

>Maybe the _real_ issue is what will break at all? The asm checks "broke"
>much more programs (glibc, linux-kernel, other kernels, drivers) then the
>aliasing stuff.

Dubious comparison at best.  Completely off the point, in my opinion.
That you even think of it that way strikes me as a fairly strange, careless
philosophy.  The asm checks broke things in a plain, visible way: code that 
no longer compiles.

Whereas aliasing problems are NOT diagnosed by anything else than programs
suddenly stopping working, or exhibiting subtle bugs.

Granted, these problems are fairly infrequent, but they were subtle enough
that ALL affected programmers have developped some degree of paranoia about
it... and don't forget that we know that checking the code by hand is the only
sure way to find aliasing problems, unless there are prototypes everywhere and
absolutely no casts.

This is an issue of overall system quality.  Stuff that stops working
in obvious ways is simple to take care off.   To wit: I managed to fix the
OpenBSD kernels __asm__ trouble, even though I don't know much about most
platforms we run on.

Right now, the problem we ran into with -strict-aliasing has led us to turn
it off everywhere by default...  this is the only safe approach, as we have
about 200 Mb of code to audit... and it is probably never going to be turned
back on again for packages, as most of these programs are not that nicely
maintained, and there's just too much code to audit.

We'd rather spend our time looking for security holes.