From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Espie To: pcg AT opengroup.org Cc: egcs AT egcs.cygnus.com Subject: Re: type based aliasing again Date: Wed, 15 Sep 1999 01:59:00 -0000 Message-id: <199909150903.LAA28886@quatramaran.ens.fr> References: <199909141102.NAA18232@quatramaran.ens.fr> <19990915020836.M3983@cerebro.laendle> X-SW-Source: 1999-09/msg00594.html 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Espie To: pcg@opengroup.org Cc: egcs@egcs.cygnus.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909150903.LAA28886@quatramaran.ens.fr> References: <199909141102.NAA18232@quatramaran.ens.fr> <19990915020836.M3983@cerebro.laendle> X-SW-Source: 1999-09n/msg00594.html Message-ID: <19990930180200.sYEvy2mQkQMOjvTxMBXtweLfVHJDvkosRbjlAAC5aHI@z> 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.