Home

Notes

Operator precedence

Message-ID: <bnews.research.310>
Newsgroups: net.lang.c
Path: utzoo!decvax!harpo!npoiv!alice!research!dmr
X-Path: utzoo!decvax!harpo!npoiv!alice!research!dmr
From: research!dmr
Date: Fri Oct 22 03:39:32 1982
Subject: Operator precedence
Posted: Fri Oct 22 01:04:10 1982
Received: Fri Oct 22 03:39:32 1982

The priorities of && || vs. == etc. came about in the following way.
Early C had no separate operators for & and && or | and ||.
(Got that?)  Instead it used the notion (inherited from B and BCPL)
of "truth-value context": where a Boolean value was expected,
after "if" and "while" and so forth, the & and | operators were interpreted
as && and || are now; in ordinary expressions, the bitwise interpretations
were used.  It worked out pretty well, but was hard to explain.
(There was the notion of "top-level operators" in a truth-value context.)

The precedence of & and | were as they are now.

Primarily at the urging of Alan Snyder, the && and || operators were
added. This successfully separated the concepts of bitwise operations and
short-circuit Boolean evaluation.  However, I had cold feet about the
precedence problems.  For example, there were lots of programs with
things like
	if (a==b & c==d) ...
In retrospect it would have been better to go ahead and change the precedence
of & to higher than ==, but it seemed safer just to split & and &&
without moving & past an existing operator. (After all, we had several
hundred kilobytes of source code, and maybe 3 installations....)
	Dennis Ritchie

Sign extension

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!genrad!mit-eddi!mit-vax!eagle!alice!research!dmr
From: dmr@research.UUCP
Newsgroups: net.lang.c
Subject: re type casting
Message-ID: <353@research.UUCP>
Date: Thu, 9-Jun-83 23:54:56 EDT
Article-I.D.: research.353
Posted: Thu Jun  9 23:54:56 1983
Date-Received: Fri, 10-Jun-83 11:37:43 EDT
Lines: 22

decvax!betz wondered about the construction

	char c;
	...  (unsigned) c;

His example was more complicated but this is the essence.  What is supposed
to happen is that the character is promoted to int, then cast to unsigned.
In other words, the sign extension is not prevented (which is what he
wants to accomplish, as portably and cheaply as possible).

In other words the v7 and DECUS compilers are wrong.  Unfortunately
they are not wrong by accident, or at least my compiler isn't.
To my shame I put in the construction as a special hack to accomplish
essentially the same thing as Betz wanted.  (This was before the unsigned
char type went in.)  In such ways do one's past sins come back to haunt one.

If you really want portability to compilers that don't have unsigned char,
I'm afraid you'll have to use the explicit mask.  At that, it may
not be too bad.  The 11 code generator would need to generate the mask
instruction anyway, and the Vax -O optimizer is smart enough to get rid of it.

		Dennis Ritchie

foo()*0

Message-ID: <bnews.research.329> Newsgroups: net.lang.c Path: utzoo!decvax!harpo!eagle!mhtsa!alice!research!dmr X-Path: utzoo!decvax!harpo!eagle!mhtsa!alice!research!dmr From: research!dmr Date: Tue Feb 1 02:08:40 1983 Subject: foo()*0 Posted: Mon Jan 31 02:52:38 1983 Received: Tue Feb 1 02:08:40 1983

A couple of years ago I changed my C compiler not to throw out 0*x, 0&x, and the like where x is an expression with side effects. I believed then and now that anyone who depended on such things was mad, and the recent examples have not convinced me otherwise. However, it was much easier to change the compiler than to attempt to argue the implausibility of each carefully crafted example. This is known in the trade as "covering your ass."

The change occurred post-v7 so it is not visible outside Bell.

	Dennis Ritchie