Comments on Initializer Proposal

[Rex Jaeschke]

I just received this input/question. Perhaps David Prosser could respond
to the author's question directly.



Date: Tue, 4 May 1993 21:18:58 -0500
From: uunet!comm.mot.com!rittle (Loren James Rittle)
To: aussie.com!rex
Subject: X3J11.1/92-046 comment and question
Organization: Systems Technology Research, Motorola, Inc.

Rex,

Earlier today, it was posted in comp.std.c:
>Although the official comment period has expired, these documents just
>became available for anonymous ftp from ftp.dmk.com in the DMK/nceg

I hope you don't mind a quick comment and question even though the
official comment period has expired.  I just obtained X3J11.1/92-046
today.

First off, I'm quite impressed with X3J11.1/92-046.  It appears to be
a well-thought, self-contained set of extensions to the C standard.
Thanks for taking your time and effort to improve C.

Section 2.1 [Compound Literals], page 2, line 8 states that
``initializers [in compound literals] need not be constant expressions
(when the unnamed object has automatic storage duration)''.  Later in
section 2.2 [Designated Initializers], this same point is not made.
Can one assume that this is an oversight and that this feature should
apply to the initializers of all objects that have automatic storage
duration?

If my assumption is the intended behavior, would it not be wise to
explicitly state the intention in 2.2.  If not, would you please
state the reason.

Regards,
Loren
-- 
Loren J. Rittle (rittleacomm.mot.com)
Systems Technology Research (IL02/2240)
Motorola, Inc.
(708)576-7794


Rex

----------------------------------------------------------------------------
(703) 860-0091  |           Rex Jaeschke              | C and C++ Seminars
rexaaussie.com  |        2051 Swans Neck Way          | and Consulting
                |     Reston, Virginia 22091, USA     | 
----------------------------------------------------------------------------
X3J11 member and US International Representative to ISO C (WG14)
Convener of X3J11.1, the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------