Standard C Digest - V2 #9

[Orlando Sotomayor-Diaz]

ANSI Draft of Proposed  C Language Std.

Mail your replies to the author(s) below or to cbosgd!std-c.
Cbosgd is reachable via most of the USENET nodes, including ihnp4,
ucbvax, decvax, hou3c....  Administrivia should be mailed to 
cbosgd!std-c-request.

ARPA -> mail to cbosgd!std-c at BERKELEY.ARPA (+++ NOT TO INFO-C +++)

**************** mod.std.c  Vol. 2 No. 9  1/11/85 *******************

Today's Topics:
	Observations from Larry Rosler (1)
----------------------------------------------------------------------

Date: Jan 10 23:24 EST 1985
From: ihnp4!attunix!lr (Larry Rosler)
Subject: std-c observations

I don't have time to respond now to all the recent activity.
Here are just a few observations.


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.  To choose the most obvious example, the adoption
of the six-significant-character case-irrelevant restriction for external
names does not invalidate all UNIX-TM code.  It is not expected that any
UNIX compiler would be degraded to impose that restriction.  (As evidence,
the UNIX System V Release 2 compilers have just gone to completely
significant external names.  Should we backtrack?)  What is expected
is that programmers who want to write code that is portable to the maximal
number of environments conform to the most restrictive characteristics of
those environments, all of which are considered to be strictly conforming
to the standard.

This does not imply that the standard is the least common denominator of
all implementations.  Quite the contrary.  In areas over which they have
control (compilers and libraries), the implementors have agreed on a
standard that is advanced beyond even System V and 4BSD.  The latter
include void, enum, non-unique structure and union member names, structure
assignment, structure arguments, structure-valued functions, and on and on,
which far postdate K&R.  But the standard also includes features from
C++ (such as `const', where the need to obviate `rofix' abominations was
apparent) and even pure inventions (such as `volatile', where the need to
control the semantics of optimized device drivers was apparent, or
`signed', to allow reliable int-like semantics for byte-sized objects).

I hope this brief explanation of the philosophy of the standard will
help to eliminate some of the misperceptions flooding the net.  Once
these principles are understood, we can begin discussing details.

Larry Rosler
Chairman, Language Subcommittee, X3J11 
ihnp4!attunix!lr
------------------------------------------------------
End of Vol. 2, No. 9. Std-C  (Jan. 11, 1985  07:25:00)
-- 
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