mod.std.c Digest V2 #11

Orlando Sotomayor-Diaz osd7 at homxa.UUCP
Tue Jan 29 10:31:56 AEST 1985


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 at 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  



More information about the Mod.std.c mailing list