== vs =

[Dave Sill]

In article <909 at micomvax.UUCP> Ray Dunn <micomvax!ray> writes:
>In article <11523 at brl-adm.ARPA> dsill at NSWC-OAS.arpa (Dave Sill) writes:
>>Does it make sense to change the language because some people have a
>>problem making the abstract <=> real transformation?
>
>Yes.  Otherwise it will eventually be the cause of someone's death, and that
>death is avoidable!

Yeah, like by using competant C programmers.

>To others who suggest defining "EQUALS" etc for "==".  This is not a
>solution.  The problem is not with the use of "==", the problem is with the
>use of "=".  The solution *has* to involve the "=" operator.

How so?  If style guidelines require the use of EQUALS or EQ instead
of == in conditional contexts, = operators will be obvious an
unambiguous.  (Of course, you could always do "#define IS =" :-)

>I do not expect any action will be taken in the current standard wars on
>this point, it is much too fundamental a problem to be "safely" addressed by
>the ANSII committee members.  It is much easier to disappear into
>intellectual paroxysms over whether "noalias" actually means "alias" etc.

It's beyond the scope of X3J11 (an ANSI, not ANSII or ASCII,
committee) to "fix" things such as this.  Their task is to codify
existing practice, not to design some new language.  (Of course some
would argue that function prototypes, `noalias', `const', `volatile',
parenthesis honoring, et cetera, are not existing practice in C, but
that's another thing...)

Face the facts: this is C we're talking about, and in C the assignment
operator is "=" and the logical equivalence operator is "==".  Like it
or lump it.  It will never change.

=========
The opinions expressed above are mine.

"A person gets from a symbol the meaning he puts into it, and what is
one man's comfort and inspiration is another's jest and scorn."
					-- Robert Jackson