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"