Path: utzoo!attcan!uunet!husc6!mailrus!ames!amdahl!pacbell!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: Leo's ANSI C Flame
Summary: Phew!
Message-ID: <6427@well.UUCP>
Date: 2 Jul 88 06:49:31 GMT
References: <8806292138.AA22025@decwrl.dec.com>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: onhigh!oracle
Lines: 172

[ "I sense great frustration, sir."  "No shit, Sherlock." ]

	Foom!  A 301-line refutation of my ANSI flame!  (This article isn't
much shorter.)  What it boiled down to was that Randy Meyers was concerned
that there is a great deal of misinformation floating around about Antsy-C,
and wanted to correct it.

In article <8806292138.AA22025@decwrl.dec.com> rmeyers@tle.dec.com (Randy Meyers 381-2743 ZKO2-3/N30) writes:
>>	You realize, of course, that this kind of optimization falls flat on
>>its face if I somehow manage to change the contents of the memory that
>>contains "abcdefg".  I could stuff a \0 where the 'd' is, and the program
>>would not notice.
>
>You are correct.  However, such a program is clearly poorly written.  [ ... ]

	I never said it was a *good* example.  I was illustrating that some
"clever" programmers may be able to find their way to that string constant
and beat on it, thus breaking the optimization.  I'd never try anything like
that, largely because it isn't clever enough :-).

>Kernighan and Ritchie never guaranteed the string constants were modifiable.

	Excuse me?  Someone else made the point that you can say:

	file = mktemp ("/tmp/ReXXXXX");

	and mktemp() will go in and bash on the string constant (since all
it knows about is the pointer it was passed).  I have been led to believe
that ANSI will break this.

> [ enormous dissertation on strlen(), part of which was: ]
>
>extern int strlen(const char *);	/* Required by ANSI */
>		   ^^^^^
	What in the name of Zarquon is a *Pascal* keyword doing in a C
program?  Does this declaration mean I can only pass string constants to
strlen()?  Can't I pass pointer variables anymore?

	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.

>	#define DESC(d, string) (d.len = strlen(string), d.ptr = string)
>
>I actually had to use a similar macro recently.  Look at what happens
>when I make a call of the form DESC(d, "abcdefg").  [ ... ]
>For example:
>
>	register char *p;
>
>	p = "abcdefg";
>
>	/* 100,000 lines of code that don't modify p */
>
>	DESC(d, p);
>
>A reasonably good compiler will prove that p's value has not been changed
>since the initial assignment, and will transform the call into
>DESC(d, "abcdefg"). With Lattice's strlen optimization, this will boil
>down into two moves, instead of a function call and two moves.
>
	Urp.  I believe the optimization is invalid in this case.  You have
declared a pointer to a string constant, and are passing the variable to the
macro.  The best the compiler can do is detect that p has not changed value,
and drop a constant pointer value (rather than actually pulling it out of p)
into the strlen() argument, and *call 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.  This is important,
since I may have made a copy of p somewhere, and used the copy to bash on
the constant, making the strlen() optimization invalid.

>>#pragma is of questionable value (largely because no one has adequately
>>explained to me what it *does*!).
>
>Every compiler is free to develop pragmas and use any syntax that
>they want after the word pragma.  [ ... ]

	Ah!  Okay, that was my problem.  I thought there was a syntax
required to follow it, like #define.  So anyone can do anything they want
with #pragma.  It could turn into a can of worms you know...

>	#if LATTICE
>	    ^^^^^^^
>	#pragma Delete(R0,R1)  /* Means delete source file to MANX */
>	#endif
>
	I thought ANSI disallowed pre-defined constants or symbols...

>>Enforced parenthetical grouping whether or not it's necessary is Stupid.
>
>Expression control is necessary, but I don't like enforced parentheses
>either.  I preferred it when the new unary plus operator controlled
>				  ^^^^^^^^^^^^^^
>expression evaluation.  [ ... ]

	Unary plus???!!?  What's *that* supposed to be for, and how can it
alter expression evaluation?

	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?

>>Breaking all the string functions and giving them cryptic names is Stupid.
>
>I agree totally.  But, I don't think that has happened.  The traditional
>functions with traditional meanings are around.  [ ... ]

	Like index(), and rindex(), and strcpy(), and strcat(), and
strtok().....?

	It's funny.  When I was briefly exposed to System V UNIX, I noticed
that all the names of the string functions were "wrong".  Along comes ANSI,
and I find that the string functions have names remarkably similar to the
broken SYS-V names.

	In an attempt to sum up, these are the problems I have with Antsy-C.
They are mostly based on second-hand information from a knowledgeable person
who has his ear to comp.lang.c, and who has been using C since way before it
became a chic language:

	o ANSI did not implement binary constants, claiming 'no prior art'.
	o ANSI held up the finalization of AN-C by flirting with a keyword
	  named 'noalias', which bought you nothing if you weren't running
	  on a supercomputer.
	o Dennis M. Ritchie is not on the standards committee, and is also
	  strangely silent on comp.lang.c with regard to opinions on what
	  ANSI has done to his language.
	o ANSI has been focusing their efforts on making the job of the
	  compiler writer easier, since the committee is populated largely
	  by purveyors of compilers; and has done little or nothing to
	  enhance C's usefulness or versatility for the programmer.
	o ANSI-C looks a hell of a lot like Pascal.  You seem to have to
	  talk a lot before you can really say anything.
	o ANSI broke the names of a lot of well-known library functions and
	  include files.
	o ANSI hasn't really resolved a lot of the irritating questions
	  revolving around C, like what NULL *really* is, or how big a
	  'short' or a 'long' *really* are.
	o The attitude appears to be, "If you had anything truly valuable to
	  say, we would have put you on the committee."
	o ANSI acts like 'void' and 'enum' are a new thing.

	Based on what I've heard from a number of individuals, ANSI has a
*lot* of crocks in it that really don't need to be there.  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'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