osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (01/29/85)
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@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