Re: criteria.html open issues

[Daniel Berlin <dan at cgsoftware dot com>]

"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

> 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?
Well, actually, yes.
What exactly is it you think package maintainers do, except maintain
packages?
This involves knowing the source code.
So for people who have been maintaining a given package for a while,
scanning for obvious aliasing problems isn't that big a deal, since
they're in all the code anyway fixing random reported bugs.

In addition to the also used bulk method of compiling it, and running
the regression tests that come with that 
software, and  then trying it again without strict aliasing, and
comparing the results.


> 
> >> 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...

What exactly are you trying to refute his point with? I don't see it.
P.J. Plauger can write sloppy code too.
If it's not sloppy, is his code full of aliasing problems, or is this
an isolated incident?  
If it's isolated, then it could just be he was working on the library
too late or something.
etc.
Did you ask him if he kicked himself in the head after hearing about
the bug? Or was it something he would have never noticed?
Regardless of any of the answers actually, it doesn't mean he can't
"get it right", it means he's not a perfect programmer, and makes
mistakes. If his code is full of aliasing problems, because he wasn't
aware of the aliasing rules, i'm with Zack here.
I have no sympathy.
If it's because of some other reason, I have sympathy, but it doesn't
make his code less buggy.


> 
> 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.
Errr, I was taught the dangers of aliasing in college, actually.

> 
> > [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){
>     ...

-- 
"Last year I went fishing with Salvador Dali.  He was using a
dotted line.  He caught every other fish.
"-Steven Wright