Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site digi-g.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!stolaf!umn-cs!digi-g!brian
From: brian@digi-g.UUCP (Merlyn Leroy <Brian Westley>)
Newsgroups: net.lang.c
Subject: Standard extensions
Message-ID: <352@digi-g.UUCP>
Date: Thu, 1-Nov-84 11:44:41 EST
Article-I.D.: digi-g.352
Posted: Thu Nov  1 11:44:41 1984
Date-Received: Sat, 3-Nov-84 03:01:17 EST
References: <>
Reply-To: brian@digi-g.UUCP (brian)
Organization: DigiGraphic Systems Corp., Mpls.  MN
Lines: 25
Summary: 

#ifdef BUG
	Just to put in my $2E-2 on Things I Would Like to C in 'C':

Why isn't there a logical XOR operator?  There is & and && for bitwise and
logical AND, | and || for bitwise and logical OR, but only ^ for bitwise
XOR.  Why can't ^^ be used for logical XOR?  This is especially annoying
since you have to say:
(a || b) && (!a || !b)  (two evals of a and b, yuck) or something like:
((a == 0) != (b == 0))	(ugly! ugly! ugly! obscure, too)
instead of simply (a ^^ b).  If you know that the true values of a and b
are identical (instead of simply being non-zero), you can say a != b, but
this is not always the case.  Why not be consistent and offer logical XOR?

The other operation(s) I would like is circular shift.  zero fill << and >>
are very inefficient if you really want a circular shift.  There is a
problem with insuring that the bit pattern wraps at the boundary you want
(8, 16, 32, etc bits), but the compiler knows the size of the operand,
and you can always typecast to force it.  The operators could be
<> and ><, or <$ and >$, or <^ and >^, or anything that isn't ambiguous.
(If any of these are ambiguous, I don't care.  I'm sure <> and >< aren't,
but they can be confusing).

/* comments? */
							Merlyn Leroy
#endif