Path: utzoo!attcan!uunet!samsung!usc!apple!sun-barr!newstop!sun!imagen!qmsseq!pipkins From: pipkins@qmsseq.imagen.com (Jeff Pipkins) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: No Aliasing Compile Option Message-ID: <135@qmsseq.imagen.com> Date: 28 May 90 14:36:25 GMT References: <4886@daffy.cs.wisc.edu> <26547195.F69@tct.uucp> <1990May19.141401.4350@ux1.cso.uiuc.edu> <265861D7.3293@tct.uucp> <134@qmsseq.imagen.com> <1990May25.150450.12924@ux1.cso.uiuc.edu> Reply-To: pipkins@imagen.com (Jeff Pipkins) Organization: QMS Inc., Mobile, Alabama Lines: 115 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.