osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (01/29/85)
mod.std.c Digest Mon, 28 Jan 85 Volume 2 : Issue 11 Today's Topics: Conditional Operator Syntax Union initialization ---------------------------------------------------------------------- Date: Sat, 12 Jan 85 21:08:06 est From: cbosgd!decvax!idis!george (George Rosenberg) Subject: Standard C Digest - V2 #7 (Conditional Operator Syntax) To: decvax!cbosgd!std-c On September 13, 1984 I sent Mr. Rosler, chairman of the ANSI X3J11 committee, some comments on draft 84-131. [ Mr. Rosler is chairman of the ANSI X3J11 Language Subcommittee. -Mod-] Those comments included among other things five apparent errors in the syntax for their language along with corresponding corrections to that syntax. Ken Arnold recently pointed out that the syntax did not account for all possible conditional expressions. Unfortunately Mr. Arnold's correction, still does not account for the following expression: a ? b = c : d My correction does account for it. Below is the relevant excerpt from what I sent Mr. Rosler. > A-2. 4.15 > example of what syntax omits: a ? b ? c : d : e > fix: > Change syntax definition of "conditional-expression" > to permit any "expression" to occur between "?" and ":". > > conditional-expression: > logical-OR-expression > logical-OR-expression ? expression : conditional-expression I would assume that those syntax errors have made it into either the current draft (84-161) or the upcoming draft. George Rosenberg idis!george ------------------------------ Date: Sun, 13 Jan 85 19:22:09 est From: cbosgd!plus5.UUCP!hokey Subject: Union initialization To: cbosgd!std-c Kevin Martin's discussion addresses my response to Dave Decot's stuff, not Dave's. I said: > >If the data used to initialize the union is appropriately cast, and that > >data type is a valid member of the union, then there is no ambiguity nor > >problem; the union will hold the value by definition, and the data will > >be appropriately cast. Kevin replied: > The problem with this method is that it lacks the ability to make > the code self-documenting. Reading the code sample you give, all I can tell > is that (for cell[1]), you are initializing one of the (char *)'s in the > union to a pointer to "abc". It doesn't tell me *directly* which element > you are initializing. > For similar reasons, it is error-prone, due to C's implicit type conversions > (e.g. if you neglected to declare (or mis-declared) the cv_char element, > or mis-cast the value, call[0] would not receive the initialization > you expected). > In addition it causes an explicit cast to behave differently from an > implicit type conversion to the same type, that is, this would be the > only place in C where > (type) (expr) > would be different from > (expr) /* implicitly cast into (type) */ Last things first. The whole point behind a union is to provide a mechanism for implicitly typing data. Kevin's last paragraph is true simply because the behavior he describes is the way unions are *supposed* to behave. While I agree the method I described is not as self-documenting as Kevin's, my method is much closer to the initialization mechanism used by structures. I have no objection to *permitting* keyword initialization (versus positional initialization), but I don't want it to be *required*. Furthermore, if we are going to permit keyword initialization for unions, we must also allow it on structures (again, for self-documenting code). Hokey ------------------------------ End of mod.std.c Digest - Mon, 28 Jan 85 19:22:28 EST ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> replies to cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above. -- Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Red Hill Road /Middletown, New Jersey, 07748 (HR 1B 316) Tel: 201-949-9230 /UUCP: {ihnp4, houxm}!homxa!osd7