Assignment in test: OK?

Thomas Truscott trt at rti.rti.org
Fri Sep 21 00:25:11 AEST 1990


> ... changing the common = to not return a value will not affect 99% of the
> lines in a typical program, and it will catch the beginner's if (a = b).

But it will not catch the beginner's (or my) if (a := b).
Will it catch if (c := getchar() != EOF)?
Adding ":=" introduces new opportunities for typographical mayhem.

It will not catch:
	if (a == b && c == d)
		a == b + 3;
I have made that mistake more than once, and the last time it happened
I spent a long time hunting it down.  (Yes, lint would have caught it.)
If the compiler had just said "null effect", I could have fixed
the problem as trivially as if I had misspelled a variable name.

I guess people think this problem is a syntactic one because:
(a) Most other language compilers they have used do not have this problem
(b) The C "==" syntax for comparison is different from the usual "="
But the omitted details are:
(c) Most other language compilers do not support assignment as an operator
(d) Most other language compilers have decent diagnostics

	Tom Truscott

APPENDIX: A MORE SERIOUS SYNTAX PROBLEM THAN =/==
Let's look at a serious "flaw" in C syntax that no one complains about.
Why not?  Because compiler diagnostics keep problems from occurring!
In C, to index a two dimensional array one uses
	n = x[i][j];
This is "gratuitously" different than other languages.
Look at how horrible the following plausible C mistake is:
	n = x[i,j];
Oh no, the dreaded comma operator!  The effect is identical to:
	n = x[j];
And C compilers will gladly generate executable code for it.
What a mess it would be tracking down the bug.
You may claim "but no one makes that mistake".  Untrue!
As a C instructor I routinely notice people fixing that mistake.
I never have to help them, thanks to a little compiler message:
	... Warning ... illegal combination of pointer and integer
I claim that if that compiler message were not printed,
the "comma operator botch" would be the favorite
complaint of FORTRAN-oriented C bashers,
even more popular than complaints of "no variable sized arrays"
or "no complex data type".  Can you prove me wrong?



More information about the Comp.lang.c mailing list