Path: utzoo!attcan!uunet!nuchat!sugar!peter From: peter@sugar.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: Leo's ANSI C Flame Message-ID: <2244@sugar.UUCP> Date: 3 Jul 88 12:51:01 GMT References: <8806292138.AA22025@decwrl.dec.com> <6427@well.UUCP> Organization: Sugar Land UNIX - Houston, TX Lines: 92 Yes, Leo, ANSI contains much that is dain bramaged. But it's not that bad. My person bitch is with compiler writers that implement part of the draft and surprise you. In article <6427@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > program? Does this declaration mean I can only pass string constants to > strlen()? Can't I pass pointer variables anymore? No, it means that strlen() guarantees it won't modify its argument. > Coming back to strlen(), I was trying (unsuccessfully, I gather) to > point out that, IMHO, a C compiler really has no business looking at > function calls (which are outside its domain), and trying to figure out what > the programmer *really* wanted to call. If I call strlen(), dammit, I > expect strlen() to be called. I will turn any and all such optimizations > off, since it's too easy for the compiler to foul it up. Fine, look in your hypothetical ANSI include file. You'll find something like this: #define strlen BUILTIN_STRLEN And it's BUILTIN_STRLEN that the compiler will turn into an inline. Actually, I think the "correct" name of this function is "stclen()" anyway, since it returns a count. You don't like this, just #undef strlen. > If the compiler were to resolve it to 'DESC (d, "abcdefg")' it would > be an error, since that would compile a *different* copy of the string > constant into memory, unrelated to the one p points to. No, since ANSI allows the compiler to allocate one copy only of each string and cons up multiple references to it. This, by the way, definitely would break the cntrl() macro I quoted a little way back. I'm not sure I like this feature, myself. > Unary plus???!!? What's *that* supposed to be for, and how can it > alter expression evaluation? The idea was that you'd say "+(expr)" and it would treat that expression as atomic. > My problem with enforced parentheses is that constructs such as: > #define FOO(x) ((x) + 15) > thing = FOO (i + 4); > ...Which compiles to... > thing = ((i + 4) + 15); > ...Which means that the compiler first adds four to i, then adds 15 > to it. Wouldn't it be nicer if it just added 19? It will. You are allowed to make optimisations that do not alter the value of the expression. About the only place this actually makes a difference is when you're dealing with floating point numbers, since floating point arithmetic is not always associative. > Like index(), and rindex(), and strcpy(), and strcat(), and > strtok().....? All but the good old index/rindex. I find it ironic that the ursurper strchr got ursurped in turn with stpchr. > My aformentioned > friend made the observation, "If I can't take a valid K&R program that > passes 'lint' and run it through a dumb filter program and get an ANSI > program out the other side, I'll consider ANSI to be a complete and utter > loss." I believe that an ANSI compiler will accept a valid K&R program, no filter needed. But I only have the '85 version of the draft, so don't bet money on it. > > I'm prepared to sit back and watch to see what happens. In the > meantime, I'm keeping my K&R compiler, since it's worked great so far, and I > like to think I've written some pretty decent code with it. > > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ > Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU > \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac > O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") > "Hmm, you're right. Air is made up of suspended meat loaf." -- Josh Siegel -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "Running DOS on a '386 is like driving an Indy car to the Stop-N-Go"