Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!princeton!allegra!ulysses!gatech!mcnc!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP Newsgroups: comp.lang.c Subject: Re: lvalues Message-ID: <889@dg_rtp.UUCP> Date: Sat, 24-Jan-87 15:18:53 EST Article-I.D.: dg_rtp.889 Posted: Sat Jan 24 15:18:53 1987 Date-Received: Thu, 29-Jan-87 03:58:59 EST References: <252@merlyn.UUCP> Lines: 50 Summary: folks have some badly mistaken notions about lvalues > brian@merlyn.UUCP (Merlyn Leroy) >> ??? >>..Assignment >>to a bit-field cannot be explained in terms of lvalue and rvalue, >>but only in terms of extractor/updater functions. Why not? Granted, to do so gives up the principle that lvalues can always be converted to addresses via '&', but this is already not the case for other reasons. Further, assignment to bit-fields IS NOW defined in terms of lvalue/rvalue in K&R, H&S, and the current X3J11 draft. Again... why not? >> The expression >>designating a bit-field cannot be evaluated to yield a context-free >>representable "value" that can be passed around, stored &c. Hence there >>is no lvalue of a bit-field. This is a non-sequitur. The statement before the "hence" is incorrect, and even if correct would not imply the statement after the "hence" (which is also incorrect). Bit-field expressions evaluate quite successfully to "values" when they are evaluated where lvalues are not permitted (to use the X3J11 terminology), and evaluate equally successfully to "lvalues" when they are evaluated where lvalues ARE permitted (such as to the left of an assignment operator). As noted above, lvalues are permitted as the operand of unary '&', while bit-fields are not. But this has nothing to do with the assignment operators. > This [the above non-sequitur] > is true of most machines; however, the new TI graphics chip is > bit-addressable, and pointers to bitfields are perfectly legal. > (This is of course a non-portable extension). This is also a good > argument for little-endianism. Well, first, the "this" from above is not true of any machines. Further, the advantage of little-endiansim referred to here has little to do with bit granular addressing, but rather to do with certain kinds of type punning. Big-endianism, of course, has a different set of advantages in type punning. I am speaking as one who has programmed a marvelous big-endian machine with bit-granular addressing, and spent considerable time thinking about what would be better and what would be worse if the machine were little-endian, so you can take my word for it. :-) -- All prediction is difficult, especially about the future. --- Nils Bohr -- Wayne Throop !mcnc!rti-sel!dg_rtp!throopw