Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!sdcsvax!ucsdhub!jack!man!nu3b2!rwhite
From: rwhite@nu3b2.UUCP
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <792@nu3b2.UUCP>
Date: Thu, 9-Jul-87 20:44:33 EDT
Article-I.D.: nu3b2.792
Posted: Thu Jul  9 20:44:33 1987
Date-Received: Sun, 12-Jul-87 09:55:02 EDT
References: <8212@brl-adm.ARPA>
Organization: National University, San Diego
Lines: 86
Summary: The Short Form.


In general x = y = z as a "C" statment is simply a short way to write
y = z;
x = y;

If we make z long, y short, and x int and we invoke the pruposed change
we get the unique situation that any of the following sequences MAY
or MAY NOT evaluate as true on a machine depending only on the size
of the types:
after x = y = z;

( x == y || y == z || x == z) WILL BE FALSE ON SOME MACHINES

Part of the idea of x = y = z where y is the smallest range(ed) type is
that  x and y WILL BE EQUAL on subsiquent tests for all ranges and returns
of z.  If x is the smallest range(d) type x and y WILL BE EQUAL only for
those ranges and returns of z which are valid for x.  This is one of the
core issues of return validation under "C".

The question can be simplified to:

Do you think: y = z; x = y; if (x == y) {...};
AND	    : x = y = z; if (x == y) {...};
shoul behave the in a identical manner on all machines?

Before you say no, consider flag masking and complex algebra.  Simple
functions like:

#define	FLAGPART	0x003f
#define ERROR		0x0010

...

	if ((tempval &= FLAGPART) != ERROR) {
		/* Process Other VALID Flags */
		}
	else {
		/* Process Error Flags		*/
		}

Yes, there are other ways to write this, but as the things get more
complex, how would you like to descover that all your temporary variables
contain masks instead of values.  Or even worse since ++x is identical
to x += 1 and x = x + 1 then l = n[++x] equals l = n[(x += 1)] always
yeilding the first element of n or l = n[(x = x + 1)] with x as
enum and n demensioned in the enum type maxenum which is undefined
unless this trick is applied to enums with special quantities [like char]
which wrap in their domain if x = makenum n[++x] is OUT OF BOUNDS in
the PERPOSED system [max + 1] but a valid wrap in STANDARD "C"

To the claim that x = y = z is too prone to simple types without the
mod, I directly say:

1) PAY ATTENTION WHEN YOU CODE.

2) IF YOU ACCEDENTLY TEND TO WRITE y = x = z you will probably write
	x = z = y or
	x = y;
	y = z;
	and miss the difference, it is an OVERSITE of equal precidence
	and equal danger.

If you try to "protect" the programmer until assignment ORDER dosn't
matter [and to put it simply that IS what you are trying to do] then
your results wont matter either.

The SHORTCUTS in "C", like multiple concatinated assignment and all the
opp-equals [etc], are for ease of coding without excess size or complexity
they never were intended to prevent the careless from making mistakes.
If you add, and keep adding, protections you will have COBOL when you
are finished.  The reasons things in "C" have a "scanning" or "grouping"
direction is because they are scanned and/or grouped out to their
EXPLICIT form.  x = y = z is NOT give x and y the value of z, it IS
give y the value of z and then give x the value of y, [you will note that
it groups RIGHT TO LEFT]  this is correct an should not be changed.  The
value of this is obvious, contains no abstractions, and is not dependant
on anything other than programmer intent.


Robert.

Disclaimer:  My mind is so fragmented by random excursions into a
	wilderness of abstractions and incipient ideas that the
	practical purposes of the moment are often submerged in
	my consciousness and I don't know what I'm doing.
		[my employers certainly have no idea]