mod.std.c Digest V2 #13

[Orlando Sotomayor-Diaz]

mod.std.c Digest            Mon, 28 Jan 85       Volume 2 : Issue  13 

Today's Topics:
                     Larry Rosler's observations (2)
----------------------------------------------------------------------

Date: Sun, 13 Jan 85 19:22:23 est
From: cbosgd!plus5.UUCP!hokey
Subject: Larry Rosler's observations
To: cbosgd!std-c

I am not a member of the C committee.  I am a voting member on the /usr/group
Unix committee as well as ANSI X11.1 (Mumps Language).  I have rarely been
accused of being opaque.

Standards bodies are very conservative.  This is both good and bad.  It is
good because it provides a mechanism for specifying bounds for portable
behavior.  It is bad because issues are sometimes decided in favor of
and existing, partial solution to a problem instead of a fuller (but
incompatible) solution.

The decision to initialize based on the lexically first member is a bad
decision because it is guaranteed to be less than a full solution.  It is
a "false freedom".  I would *greatly* prefer that the committee left the
decision undecided rather than implement a partial solution.

I think it is swell that Whitesmith's added some chrome to their C compiler
and their users thought it was Good.  I would hope the committee wasn't
satisfied with Somebody standing up and saying "We did this and our user's
all Love it" without checking around.  In any event, this sort of discussion
is EXACTLY the reason I have been pushing so hard for mod.std groups - they
provide a mechanism for a much larger audience to participate in the decision-
making process for Standards in an ongoing fashion.  If "problems" can be
solved over the net before the meetings, the meetings will go much faster
and the quality of the decisions will be higher.  But I digress.

> 3.  No one on the committee can offer a "better" solution that has already
>     been implemented and widely used.

Perhaps that is because nobody has found a solution that satisfies the problem.

(ANSI X11.1 spent over 5 YEARS deciding how to deal with environment control
and parameter passing.)

I do not mean to denigrate the effort which has gone into the proposed C
standard.  I certainly applaud many of the advances set forth in the document.
Please realize I am attempting to get the most out of the standard.

Hokey

------------------------------

Date: 12 Jan 85 19:27:27 CST (Sat)
From: cbosgd!ihnp4!trwrb!desint!geoff
Subject: Larry Rosler's observations
To: cbosgd!std-c

Larry Rosler writes regarding the union-initialization suggestions:

>All the invention about union initialization is undoubtedly fun,
>but besides the point for the standardization process.  In a nutshell:
>1.  The committee recognizes a problem worth addressing
>    (union initialization).
>2.  An existing widespread family of implementations (Whitesmith's Ltd.,
>    obviously unknown to most readers of the net) has had a solution to
>    this problem for years -- initializing the lexically first member --
>    which they report has satisfied the needs of their users.
>3.  No one on the committee can offer a "better" solution that has already
>    been implemented and widely used.
>4.  The Whitesmith's solution is accepted "faute de mieux".
>
>The standard is not intended to break any code that exists and is valid
>in its own environment.

I have two problems with this.  The smaller one is that there is an
implication here that any compiler company can impose a de-facto standard by
inventing something first and getting it out into the field where people can
make use of it.  (Yes, I know about Whitesmith's.  Two years ago I spent a lot
of time converting Whitesmith putfmt's to printf's.  I do not associate that
company with standardization!)

My larger problem is that, because one company with a relatively small user
base (Larry did note that most of us have never heard of or used Whitesmith's
stuff) has a "solution" that "they report has satisfied the needs of their
users," we are locking ourselves into an untenable future.

    (1) I suspect that, if you had queried AT&T two or three years ago, they
	would have reported that C with no union initialization at all
	"satisfied the needs of their users".  It is obvious that there are
	cases where it would be desirable or even necessary to initialize
	arbitrary union members.
    (2) If we adopt the initialize-first-member rule for this draft of the
	standard, will we have an "upgrade path" in the future that will allow
	arbitrary initialization without breaking existing programs that use
	the initialize-first-member rule?  My fear is that we are creating
	another 6-character-identifier situation here.

	Geoff Kuenning
	...!ihnp4!trwrb!desint!geoff

------------------------------

End of mod.std.c Digest - Mon, 28 Jan 85 21:03:03 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) below.
-- 
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