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]