🚀 go-pugleaf

Wow, major opinions!  Here we go one more time:

>I don't know where you've been, but where _I've_ been it _has_ been
>considered bad practice to use aliasing.  Not bad _morally_ or
>_legally_ (how silly) but bad from a program maintenance point of
>view:  it's difficult for someone other than the person who wrote
>the code to understand, correct, and/or modify the code.  Sometimes
>it can even be difficult for the person who wrote it (!).

I agree with the sentiment expressed here.  Maintenance and reliability
are the most important qualities of good code.  More important than
speed.

But anyone who has ever passed a pointer to a function, or written a
function that takes a pointer as an argument, has used aliasing!
Now, it's true that the compiler only cares about the names that exist
simultaneously in the same scope.  But if you write a function that
takes a pointer, and someone calls it by passing the address of a
global, that's aliasing.  (Of course, none of the respectable programmers
here would ever use globals anyway ;-).
-----------------------------------------------------------------------
>It's also an UNSAFE assumption to optimize array references - strictly
>speaking, you should have bounds checking on ALL array references
>(C. A. R. Hoare has quite a bit to say about this).  Many people find
>that this produces programs that run too slowly for their purposes,
>and find it useful to have a switch to remove array bounds checking.

>If you _really_ want to avoid this sort of thing, you should NOT be
>using C!!!   It's just not possible to avoid possible problems of this
>sort in anything remotely approaching the full language -- for example,
>as soon as you use the ++ operator on a pointer, you have done an
>operation semantically equivalent to an _unchecked array reference_.

>Peter Norton once made the remark that C was an industrial strength
>language, and that many people got the impression that what they
>needed was an industrial strength language without realizing that
>"industrial strength" also means "unsafe for children and small
>animals".

I think we are changing the subject slightly, but even though C is an
industrial-strength language, which makes it useful, that is no reason to
abuse it or to forego safe coding practices.  In fact, we should develop
habits that help us write safer code (that doesn't mean giving up power).
Here is my favorite example:

In general, you can encourage yourself to write more reliable code by
always using the braces {} in if-else statements, even if there is only
one line of code in them.  That is because there is a language ambiguity
that is resolved with semantics.  This semantic resolution can be avoided
by using the braces.  If you write this code:

    if (cond) 
       stmt1;
    else
       stmt2;

It will work fine until it is modified (by you or someone else) like so:

    if (cond) 
       if (cond2)
	  stmt1;
    else
       stmt2;

Now of course we should all argue that "someone else" is an idiot and
shouldn't modify it in such a way as to break it.  (now the else clause
sticks with the if (cond2).)  In this simple example it is easy to see
that it is incorrect.  In real-life examples, as you know, it is not
always so obvious.  But if the braces are always used, this can never
happen:

   if (cond) {
      stmt1;
   }else{
      stmt2;
   }

I'm not saying we should try to write code that nobody else can break
by modifying it -- that's obviously rediculous.  I'm just saying that
there are some simple things we can do to protect ourselves and make
our code safer in general.  If you always use the braces around everything,
you will never even have to check to see if there is a dangling else
problem.  You will know that there isn't.  And extra braces don't cost
anything at run time.

I'm way off the subject of aliasing now, but my theme is still the
idea that we can write safe code with C, without giving up any power to do it.
----------------------------------------------------------------------------
>>POINT: Not only should the option not be used to compile benchmarks, IT SHOULD
>>NOT EVEN BE AN AVAILABLE OPTION FOR THE COMPILER IN THE FIRST PLACE!

>UTTER BULLSHIT. Belive me, I EXPECT that optimization to be present - 
>if YOU don't like fast code, simply turn it off. I know how to 
>code so it will not cause problems. Just pretend you are
>writing, for instance, Fortran. I have NEVER had it break any of my code.

Did I say that I didn't like fast code?  I just said that I preferred code
that works over that which doesn't, but is faster.  If you truly want
your code to be faster, significantly faster, you replace an algorithm
with one that is more efficient.  Like use a quicksort instead of that
selection (or bubble (gasp)) sort.  Replace that sequential search with
a binary search, or replace the binary search with a hash table.
Code "squeezing" only buys you a little efficiency in comparison.
I realize that I don't have to use the -Oa option.  That wasn't really
the point.  The point was that the author of a program (in this case,
a compiler) should not encourage its users to abuse it.  IMHO, that
is what -Oa is about.

=============================================================================
Jeff Pipkins
pipkins@imagen.com
My opinions are not necessarily shared by anyone, as is apparent from the
responses to my last posting ;-).  I appreciate hearing from those with
different views.