Re: criteria.html open issues

["Albert D. Cahalan" <acahalan at cs dot uml dot edu>]

Zack Weinberg writes:
> On Mon, May 28, 2001 at 02:46:44AM -0400, Albert D. Cahalan wrote:
>> Zack Weinberg writes:

>> I do not believe that this is true. Most programs have code
>> paths that are poorly tested. Error handling is a common case.
>
> The version of 2.96 shipped with Red Hat Linux 7.x has strict aliasing
> on at -O2.  The system integrators went to considerable length to find
> and squelch these bugs.

How, by examining gigabytes of source code?

>> Very few people are even aware that aliasing is dangerous.
>> I work in a UNIX-centric environment with experienced OS
>> developers, all of whom were surprised (and horrified) to
>> see what the new compiler would do. Even more disturbing
>> was that "volatile" wouldn't fix the problem.
>
> I have zero sympathy.  With the exception of kernel-level code, I have
> never seen a -fstrict-aliasing -exposed bug that was not simply sloppy
> programming.

I saw the bug in P. J. Plauger's example C library. He was on
the ANSI C standard committee, doing the library part of the
standard. If he can't get this right...

Step outside the world of compiler hackers, and see how many
experienced software developers know about this stuff. It isn't
taught to college students either.

> [Note that I was, and am, in favor of the __norestrict__ feature that
> was proposed back then, for code that genuinely does need to bend the

This is how people fix their code:
#define MEMORIZE(x) __asm__ volatile (""::"r"(&(x)):"memory")

Adding "volatile" didn't work, and there was too much code
to switch over to unions.

I think there is/was a pretty clear bug here in fact, even if you
do love the strict aliasing behavior. Here:

void foo(volatile float f){
  volatile unsigned *u = (volatile unsigned *)&f;
  if(u&WHATEVER){
    ...