donn@utah-cs.UUCP (Donn Seeley) (01/18/88)
I know Usenet is a treasure trove of arrogant and opinionated statements, but I just couldn't let this pass without adding some of my own. I'm going to quote some of Gwyn's remarks out of context for the purpose of ridicule -- feel free to check these quotes against the original articles and judge for yourself whether this is unfair. Actually, my real response to this is that such backward porting hasn't been a concern of the committee, so far as I can tell, and rightfully not. <7022@brl-smoke.ARPA> 'The committee couldn't care less whether existing implementations can run correctly written ANSI C programs.' And another goal is to remedy clear deficiencies. <7053@brl-smoke.ARPA> 'The committee feels free to ignore existing practice if it will help solve political problems.' I feel that it was and is possible to have a standard that would maximize interchange of software between existing C implementations and would minimize the work required to bring nonconforming implementations into line. As a programmer, I can't imagine why a standard that doesn't do this would be useful to me. I am appalled at the contempt Gwyn and the committee seem to feel for this idea. My own arrogant and opinionated feeling: C was not invented to solve every programming problem. Other languages have done and will do many things better. What C does do, it does well, and it proves this by the enormous body of software which has been written in it, written entirely without the graces of a formal standard. I'm not impressed by people who want to change C to 'advance the art', any more than I am impressed by 62 options to 'ls' or 'cat'. C is no longer a vehicle for advancing the art; C IS art. I have to admit, in spite of this tirade, that I don't feel any particular fear at the inevitable onslaught of ANSI C. Well before the time its forces have conquered and occupied the enemy territory, I will be writing my own programs in (say) C++, a language which really is advancing the art, and which has yet to be 'improved' by committee... The rest of you may have my condolences. Donn Seeley University of Utah CS Dept donn@cs.utah.edu 40 46' 6"N 111 50' 34"W (801) 581-5668 utah-cs!donn
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/25/88)
In article <5212@utah-cs.UUCP> donn@utah-cs.UUCP (Donn Seeley) writes: >'The committee couldn't care less whether existing implementations can >run correctly written ANSI C programs.' I'm not aware of ANY programming language standard (except possibly for Minimal BASIC, which nobody uses) that had as a goal what Donn apparently wants for the C standard. The lowest-common-denominator intersection across all C implementations is just too small to waste time on, since nobody would want to use such a puny subset. If you don't believe this, then you must not have encountered a significant fraction of the many existing C implementations. > And another goal is to remedy clear deficiencies. > <7053@brl-smoke.ARPA> >'The committee feels free to ignore existing practice if it will help >solve political problems.' It takes quite a leap of logic to conclude that these are equivalent! X3J11 has by no means been "ignoring existing practice"; to the contrary, a continual goal has been to ensure that Standard C implementations will be able to support existing correctly-written C source code. >I feel that it was and is possible to have a standard that would >maximize interchange of software between existing C implementations ... That is NOT the goal of the C standard nor of any other major language standard. Existing implementations simply differ too much to make this a better alternative than arranging for FUTURE enhanced portability across much richer and more useful C environments. We cannot, of course, guarantee portability of existing applications among existing implementations, since whether or not they are portable is already determined and is not changed by adopting any sort of a "standard". >As a programmer, I can't imagine why a standard that doesn't do this would be useful to me. I suggest that you attempt this feat, and see what you end up with. Be sure to include IBM 370, Honeywell, H-P 3000, MS-DOS, Macintosh, etc. in your list of pre-existing implementations to be included in your "standard". At best, you'll end up with some "portability guidelines for C programming", such as you can find in several textbooks. Such "portability" is either too weak to be useful, or else it requires defining a lot of implementation-dependent parameters in header files, providing a lot of OS interface routines, etc. The implementor ends up doing about as much work to provide such a "portable" environment as with the more usual approach taken by X3J11. The programmer generally ends up with MORE work with such an approach, since the less that things are specified, the more that (portable) code has to be written in terms of parameters. I fail to see what service that would be to the C community! >I will be writing my own programs in (say) C++, a language which really is >advancing the art, and which has yet to be 'improved' by committee... Just wait until the C++ variants start multiplying. Then those trying to write portable "production" applications will clamor for standards for C++! It is true that you don't need programming language standards much if you're doing CS research rather than production programming, or if you don't have to support more than a few types of system. It is also premature for C++ to standardize much, since it is still undergoing change. It's the major reason that I will still be using C rather than C++ in the near future for applications that we fully expect to be in heavy use 20 years hence. Since you've been so obnoxious about this, I'll report that we had one hell of a time trying to import code written at your institution, due to its being terribly dependent on features present in a particular C compiler you used but not promised by K&R and in fact not present in at least one of our local compilers. (In fact, the need to avoid such hassle was one of three major determinants for the type of computer and OS we subsequently bought. We opted to get one just like yours! Clearly this situation is to be avoided if possible.) Note that much of this non-portable C usage was for the express purpose of getting around deficiencies in the K&R-specified language, things that the new C Standard will be requiring portable support for in future C compilers. Seems to me X3J11 is doing the job right, plus or minus epsilon.
mwm@eris (Mike (My watch has windows) Meyer) (01/28/88)
Did Doug post something about the new dpANS having a different
treatment of exit? I can't think of any other reason why Rahul keeps
harping on like so:
In article <1962@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
<Can't argue with this sentiment. I doubt very much, though, that you
<will find a high level of consensus in favor of ANSI's stand on the
<exit(zero/nonzero) issue outside of the ANSI committe itself. It seems
<to be essentially VMS users versus everybody else.
Every C implementation I've used except for some old VMS C and
pcc-ported-to-VMS compilers used exit(0) -> everything is fine,
exit(something that isn't 0) -> things aren't find, and what isn't
fine and how far it is from fine depends on the environment.
The draft I've got my hands on says:
void exit(int status)
[...]
if the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. If the value of status is
EXIT_FAILURE, an implementation-defined form of the status
unsuccessful termination is returned. Otherwise, the status is
implementation-defined.
This means that things written for the environments I've dealt with
outside of VMS will work as well as before. And it also gives us a
pair of defines (one of which can presumably be 0 everywhere,
including VMS) for good/bad exits. Seems like a good thing to me.
<mike
--
Come all you rolling minstrels, Mike Meyer
And together we will try, mwm@berkeley.edu
To rouse the spirit of the air, ucbvax!mwm
And move the rolling sky. mwm@ucbjade.BITNETgwyn@brl-smoke.ARPA (Doug Gwyn ) (01/30/88)
In article <1962@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I doubt very much, though, that you >will find a high level of consensus in favor of ANSI's stand on the >exit(zero/nonzero) issue outside of the ANSI committe itself. It seems >to be essentially VMS users versus everybody else. Not necessarily. There has always been a need for a well-defined failure status code, or do we insist that all non-zero values indicate failure? (They don't on UNIX; it's the value modulo 256.) Note that Whitesmiths Ltd., purveyors of the first non-AT&T C compilers across a broad range of target operating systems, defined similar macros long ago. VAX/VMS just happened to be the system with a vocal adherent on the committee; but that doesn't mean that his request was bogus.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/30/88)
In article <7196@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >There has always been a need for a well-defined >failure status code, or do we insist that all non-zero values indicate >failure? (They don't on UNIX; it's the value modulo 256.) I hear what Doug says. I think we ought to at least insist that a small positive value (e.g. 1..maximum value of unsigned char) represent failure. I'm alarmed that an implementation that treats exit(1) or exit(2) (or BOTH) as a successsful status can be ANSI-conformant. It's simply too great a departure from established practice. Probably 98% of all existing C programs--rough guess--do exit(1) or exit(2) on a serious error. I just don't see how the trivial benefit of avoiding a one-line encapsulation exit(i) int i; { _vms_exit (i ? SYS$_FAILURE : SYS$_NORMAL); } justifies the lack of upward compatibility. ANSI could simply "deprecate" the use of arbitrary positive values in preparation for a complete switch to just two exit symbols in a future revision of the standard. The above should not be taken as criticism of ANSI or Doug Gwyn in general. I'm sure he is a valuable asset to the standardization effort, and he's definitely a valuable link between ANSI and the net. It *should* be taken as criticism of this particular decision. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
donn@utah-cs.UUCP (Donn Seeley) (01/31/88)
Honest, I wrote my anti-ANSI C piece without having read a word of the anti-ANSI Fortran flames in comp.lang.fortran recently... I just caught up with that newsgroup and there were some exceedingly familiar remarks about how ANSI is treating another language standard: The following are selected ballot comments from some of the committee members who voted NO to forwarding the proposed standard for public review: IBM: "The difficulty with 8x lies not in the quality of the work that X3J3 has done but rather in the somewhat surprising observation that the result of X3J3's work is a new language, and not a revision of FORTRAN." DEC: "We believe that publishing this document may jeopardize the past successes of FORTRAN in its attempt to make several major changes to the language." Unisys: "We feel that the addition of the entire package of modern programming language features has warped the language nearly beyond recognition. It is our opinion that the committee has spent too much time in language design at the expense of standardizing current practice. We fear the proposed language will no longer serve the community for which it was originally designed. The promoters of the modern language additions, on the other hand, contend that the language already fails to serve that community and that if the committee does not make drastic changes to the language, users will abandon it in favor of a modern language such as Ada. Our reply is: Let them use Ada. To paraphrase Mark Twain, we believe the predicted demise of FORTRAN has been greatly exaggerated." BOEING: "The standard has deviated too far from FORTRAN 77." [From: 'Summary of the FORTRAN 8x Issues', Presley Smith and Bob Metzger, CONVEX Computer Corporation; <68000005@convex>] Of course the magnitude of the rape of Fortran makes C quite innocent by comparison (Smith and Metzger report an IBM claim that by several statistical measures, Fortran 8X is more complex than Ada), but I hope y'all see that the principles (or lack thereof) are the same in both cases. Donn Seeley University of Utah CS Dept donn@cs.utah.edu 40 46' 6"N 111 50' 34"W (801) 581-5668 utah-cs!donn
di3000@whutt.UUCP (SEVENER) (02/05/88)
In article <5230@utah-cs.UUCP>, donn@utah-cs.UUCP (Donn Seeley) writes: [ most of the article, and all of its content deleted :-) ] > > Of course the magnitude of the rape of Fortran makes C quite innocent > by comparison (Smith and Metzger report an IBM claim that by several > statistical measures, Fortran 8X is more complex than Ada), but I hope > y'all see that the principles (or lack thereof) are the same in both > cases. > > Donn Seeley University of Utah CS Dept donn@cs.utah.edu > 40 46' 6"N 111 50' 34"W (801) 581-5668 utah-cs!donn Actually by many non-statistical measures, FORTRAN has ALWAYS been more complex than ADA (substitute any favored language here! :-)) Just *see* the way any compiler writing text warns people off FORTRAN! In fact, I like the results of dpANS C, with the exception of this GODAWFUL mess of noalias. Michael Siemon AT&T Bell Laboratories (try ...!ihnp4!mhuxu!mls) standard disclaimer.
ray@micomvax.UUCP (Ray Dunn) (02/17/88)
In article <5222@utah-cs.UUCP> donn@utah-cs.UUCP (Donn Seeley) writes: > (PS -- In >case it wasn't obvious, I don't represent the University of Utah or >Berkeley Unix any more than Doug represents the ANSI C committee.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Folks, I think the above point is exceedingly important. Doug has set *himself* up as the "spokesman" of the ANSII committee, and to a major extent it is *irrelevant* if he posts a contradiction to your views on whatever your pet gripe happens to be. His view is only that, his view! It only carries more weight than yours or mine as an individual member of the committee, not of the committee itself. It is also interesting to note, make of it as you will, that Doug's views are often very controversial, a facet that, as 'old-net-hands' will recognize, is extremely unusual in a net 'guru'. It is unfortunate that Doug often pontificates his views as though he *were* the ANSII committee when in fact a much more useful role that he could be playing is the opposite one, i.e. representing the views expressed on the net *to* the committee. On seconds thoughts however..... Ray Dunn. ..philabs!micomvax!ray
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/19/88)
In article <907@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >>Berkeley Unix any more than Doug represents the ANSI C committee.) >Doug has set *himself* up as the "spokesman" of the ANSII committee ... This is simply not so. I have posted NUMEROUS disclaimers, especially when it appears that I might be misunderstood as representing an official X3J11 position. For the most part, I simply provide information and some degree of tutoring. For example, the "noalias" issue was discussed here because of information I provided. I figured the newsgroup subscribers should hear about it at the earliest possible opportunity. Consider this another disclaimer. In the unlikely case that I were to post an official X3J11 position, I will identify it clearly as such. >... Doug's views are often very controversial, a facet that, as >'old-net-hands' will recognize, is extremely unusual in a net 'guru'. My views normally agree with Guy Harris, Chris Torek, Henry Spencer, and other established C/UNIX "gurus". The main "controversy" is that Chris and Donn Seeley seem fundamentally opposed to the idea of C standardization by committee whereas I support what X3J11 is doing for the most part. >... a much more useful role that he could be playing is the opposite one, >i.e. representing the views expressed on the net *to* the committee. You obviously do not know WHAT role I play on the X3J11 committee. I of course do not waste committee time by proposing what are in my judgement poorly thought out or otherwise ill-advised ideas that are frequently put forth on this newsgroup. But I certainly do offer proposals that I feel I can support, often based on conversations with more thoughtful members of the C user community, and some of these proposals have in fact been adopted by the committee. I'm doing my job; I suggest you do yours. (Actually, I do more than my job -- I'm not required to keep you all posted on new ANSI C developments, answer questions, give tutorials, correct errors, etc.)
ok@quintus.UUCP (Richard A. O'Keefe) (02/20/88)
In article <7290@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <907@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: > >>Berkeley Unix any more than Doug represents the ANSI C committee.) > >Doug has set *himself* up as the "spokesman" of the ANSII committee ... > I'm doing my job; I suggest you do yours. (Actually, I do more than > my job -- I'm not required to keep you all posted on new ANSI C > developments, answer questions, give tutorials, correct errors, etc.) At the last count, I have made 8 attempts to send e-mail to Doug Gwyn. Here's what I've tried to send: Thank you very much for your postings in comp.lang.c. I very much appreciate the work you put into them. I would point out to you that the BSI Prolog committee knows of the existence of comp.lang.prolog (I told them) but *NO-ONE* on that committee has ever had the courtesy to post anything to that newsgroup or the Prolog Digest. (Perhaps they are too busy inventing a new language.) Neither has there been much in comp.lang.fortran about Fortran 8X, until we were suddenly told that the review period would be over in a couple of weeks. We readers of comp.lang.c are fortunate indeed to have Doug Gwyn.
jsb@actnyc.UUCP (The Invisible Man) (02/22/88)
In article <907@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: }In article <5222@utah-cs.UUCP> donn@utah-cs.UUCP (Donn Seeley) writes: }> (PS -- In }>case it wasn't obvious, I don't represent the University of Utah or }>Berkeley Unix any more than Doug represents the ANSI C committee.) } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } }Folks, I think the above point is exceedingly important. Doug has set }*himself* up as the "spokesman" of the ANSII committee, and to a major }extent it is *irrelevant* if he posts a contradiction to your views on }whatever your pet gripe happens to be. His view is only that, his view! It [ more Doug bashing deleted ] As a member of the ANSI C committee, let me point out that I have seen no misrepresentations of the committee in anything posted by Doug to this group. Quite the contrary; Doug is always careful to clearly distinguish those points which *may* not be the position of the committee. -- jim [missing right bracket in expression (uunet!actnyc!jsb)
ray@micomvax.UUCP (Ray Dunn) (03/10/88)
In article <671@cresswell.quintus.UUCP> Richard A. O'Keefe writes: >At the last count, I have made 8 attempts to send e-mail to Doug Gwyn. >Here's what I've tried to send: > Thank you very much for your postings in comp.lang.c. > I very much appreciate the work you put into them. > Richard included this in response to a flame I wrote criticising Doug on a number of points. To a certain extent I agree with the sentiments expressed above by Richard even though (if anyone cares) I sometimes vent my frustration at some of Doug's idiosyncratic responses. If you hold yourself up as an authority, as Doug does, you must be very careful to maintain your credibility. Unfortunately, Doug often appears to not know when to keep his mouth firmly shut and leave things well alone. He appears to always need to justify everything he says or is trivially criticised for, even if this means getting into arguments which at best, border on the specious or untenable. Now, fair enough, this is Doug, and he can only act as his personality dictates, but it *is* sometimes annoying, and it leaves him open to this sort of complaint (which he should probably learn to "verbally" ignore). More important however, in my mind it denegrates the "quality" of his postings and his credibility as an authority. *Perhaps* he does not fully realize the *responsibility* of the position he has voluntarily undertaken. What does it matter if *I* spout off, who am I, but Doug has positioned himself such that his readers should be able to rely on the veracity of his remarks. He should thus be careful what he says and how he says it. Earlier gurus of 4 or 5 years ago, who, apart from the fact that they did not seem to have any axe to grind as Doug often appears to have, would rarely resort to sarcasm and downright dismissal of others views! [Mind you, Chris Torek seems to be getting a littly crotchetty in his old age these days! (:-)]. I could go on, I'll spare you though (whew!) except to say that I *do* believe that we should remember that Doug's position on the ANSI committee gives him a certain power, but *not* necessarily a superior opinion on the contentious issues we all discuss (argue? shout about? go to sleep over?...). If anyone wants to follow up this posting, please choose an appropriate news group. Don't ask me, I don't know what's appropriate, but we'd better leave this group for crying about the message rather than shooting the messengers (:-). Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/11/88)
In article <933@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >I could go on, I'll spare you though (whew!) except to say that I *do* >believe that we should remember that Doug's position on the ANSI committee >gives him a certain power, but *not* necessarily a superior opinion on the >contentious issues we all discuss (argue? shout about? go to sleep over?...). Thanks for your comments. The one real advantage that participating in X3J11 has given me is that I've heard all the arguments for changing = to := and the other such ideas that keep popping up in this newsgroup many times before. Some topics, such as = vs. ==, have probably been sparked by magazine articles, since the same old arguments keep getting repeated. To give you some idea of what X3J11 is up against, of 717 public comments from the first formal review, roughly 257 (that's 36%) were adopted in some form. The remaining 460 comments (64% of the total) had to be read, understood, discussed, and explanations of why they were not adopted had to be written. The work kept the whole committee busy for many days. It shouldn't be any wonder that some of us by this point have little patience with the same suggestions that we've had to write rejection rationale for over and over. By the way, = vs. == was indeed considered by X3J11, but what can we do about it? If it were changed, the result could not reasonably be called "C". In fact, as I recall, most of us don't even think it should be changed if it were feasible to do so. The only approach that is at all compatible with a large body of C code (but by no means all) would be to introduce Boolean expressions and require that the control conditions of if(), while(), for(), do..while() be Boolean expressions. That would solve the if ( a = 0 ) problem. But it would break so much existing code that I for one am sure that no such "C" standard [that requires a diagnostic when the Boolean-expression constraint is violated] would be generally accepted.
ray@micomvax.UUCP (Ray Dunn) (03/30/88)
In article <7436@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) replies to a posting of mine: >...... >The one real advantage that participating in X3J11 has given me is that ^^^^^^^^^ >I've heard all the arguments for changing = to := and the other such >ideas that keep popping up in this newsgroup many times before. Some >topics, such as = vs. ==, have probably been sparked by magazine articles, >since the same old arguments keep getting repeated. I always suspected Doug was a masochist!! (:-)(:-)!! To be fair to your audience Doug, you often post only conclusions, which appear to be opinions, when a little piece of the arguments considered by X3J11 would lend a lot of credence to the posting and might *sigh* suppress some of the net.traffic. E.G.: >... >By the way, = vs. == was indeed considered by X3J11, but what can we do >about it? If it were changed, the result could not reasonably be called >"C". In fact, as I recall, most of us don't even think it should be >changed if it were feasible to do so. The only approach that is at all >compatible with a large body of C code (but by no means all) would be >to introduce Boolean expressions and require that the control conditions >of if(), while(), for(), do..while() be Boolean expressions. That would >solve the > if ( a = 0 ) >problem. But it would break so much existing code that I for one am >sure that no such "C" standard [that requires a diagnostic when the >Boolean-expression constraint is violated] would be generally accepted. Now if only Doug had posted this paragraph 2 or was it 3, months ago, when the discussion started it would, I think, have suppressed much of the lunatic fringe (O.K. - include me in that if you will (:-)). We would not have had the "this isn't a problem" and "*I* don't do this so how can *anyone* want to change..." postings. Doug clearly states: a) The =/== question was thought serious enough to be considered by X3J11. b) Various approaches to solve the problem were explored and rejected. There is a *BIG* difference between saying "not a problem" and "solutions are difficult or contradict other mandates etc". I don't fully agree that a switch or pragma enabled boolean extension to the langauge is not possible to enable *future* code to be more fireproof, however I'm sure that that has all been fully discussed at X3J11 (:-). Anyone think we should open a new newsgroup to address exensions to the language in general, and X3J11 discussions in particular?? The total traffic here has got out of hand! Ray Dunn. ..{philabs, mnetor, musocs}!micomvax!ray