Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Assignment in test: OK?
Message-ID: <3797@goanna.cs.rmit.oz.au>
Date: 21 Sep 90 07:19:35 GMT
References: <1990Sep12.194753.9808@laguna.ccsf.caltech.edu> <4641:Sep1919:49:5990@kramden.acf.nyu.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 21

In article <4641:Sep1919:49:5990@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> Right. That's why you need to preserve that function, as :=. But
> 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).
...
> Furthermore, =/:=/== has an important benefit: The code-checker no
> longer needs to special-case a = b when it's looking for ignored values.

I'm getting sick of this.  If you want a language which has no = / ==
problem, Scheme, with its
	(set variable value)		;; assignment
	(eq? thing1 thing2)		;; object identity
is hard to beat.  And there's a free compiler from DEC that turns it into
C.  (Best of all, none of those nasty malloc/free errors.)  But it doesn't
look like C?  Neither it does.  Wasn't that the point?

There's a _lot_ that C compilers could usefully warn about (like
uninitialised variables, dead code, *ptr - *ptr++, and so on).  = -vs- ==
is just one case among many.
-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.