garys@bunker.UUCP (Gary M. Samuelson) (10/01/86)
In article X, someone (doesn't matter who -- I think several people have done the same thing) writes: >Then it isn't a C compiler... This is rapidly becoming one of my pet peeves. It seems that it is with increasing frequency that I see comments to the effect that if a C compiler has a bug, then it isn't a C compiler. This is pedantic; by that reasoning, there isn't a C compiler in the world, and probably never will be. Why not just say, "Your compiler has a bug," instead of, "Your compiler isn't a C compiler." My compiler has a "feature." Yours has a "bug." His isn't even C. Gary Samuelson
jason@hpcnoe.UUCP (Jason Zions) (10/06/86)
Gary M. Samuelson writes: > In article X, someone (doesn't matter who -- I think several > people have done the same thing) writes: > > >Then it isn't a C compiler... > > This is rapidly becoming one of my pet peeves. It seems that it is > with increasing frequency that I see comments to the effect that if > a C compiler has a bug, then it isn't a C compiler. This is pedantic; > by that reasoning, there isn't a C compiler in the world, and probably > never will be. Why not just say, "Your compiler has a bug," instead > of, "Your compiler isn't a C compiler." If the problem which inspired the "It isn't C" comment is just something that crept into the product, then the problem is indeed a "bug". If the problem is the result of a deliberate design decision, then the product no longer implements the C language. When creating a C compiler, there are NO design decisions to be made with respect to the language; only with respect to implementation and possible options. The case of the Silicon Graphics (I think that was the name of the machine) compiler creating a type "long float" and differentiating it from "double" falls in this latter category of a misguided design decision. -- This is not an official statement of Hewlett-Packard Corp., and does not necessarily reflect the views of HP. It is provided completely without warranty of any kind. Lawyers take 3d10 damage and roll a saving throw vs. ego attack. Jason Zions Hewlett-Packard Colorado Networks Division 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 {ihnp4,seismo,hplabs,gatech}!hpfcdc!hpcnoe!jason
levy@ttrdc.UUCP (Daniel R. Levy) (10/06/86)
In article <1215@bunker.UUCP>, garys@bunker.UUCP (Gary M. Samuelson) writes: >In article X, someone (doesn't matter who -- I think several >people have done the same thing) writes: >>Then it isn't a C compiler... >This is rapidly becoming one of my pet peeves. It seems that it is >with increasing frequency that I see comments to the effect that if >a C compiler has a bug, then it isn't a C compiler. This is pedantic; >by that reasoning, there isn't a C compiler in the world, and probably >never will be. Why not just say, "Your compiler has a bug," instead >of, "Your compiler isn't a C compiler." >My compiler has a "feature." >Yours has a "bug." >His isn't even C. >Gary Samuelson That peeves me, too, as being an overly sarcastic comment, even if spoken by a Guru. Guy Harris has made this comment several times if memory serves me right. I have not noticed any others making the comment that "it isn't a C compiler." Don't expect Guy to reply to this message (I think I'm in his kill file). -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
rcd@nbires.UUCP (Dick Dunn) (10/07/86)
> >Then it isn't a C compiler... > > This is rapidly becoming one of my pet peeves. It seems that it is > with increasing frequency that I see comments to the effect that if > a C compiler has a bug, then it isn't a C compiler. This is pedantic;... Gary's complaint is valid when people are talking about things which turn out to be bugs - meaning something along the lines of "behavior which the implementors agree is incorrect and should be fixed." But that only accounts for about half of the circumstances that elicit the "it isn't a C compiler" response. The rest are improvements foisted on us by implementors who decided they had a better idea and implemented it without understanding the language. An example of the latter showed up just recently, where some implementation had made "long float" a different type from "double". As long as people come up with gratuitous incompatible extensions to the language, they can expect the wrath of knowledgable users. -- Dick Dunn {hao,ucbvax,allegra,seismo}!nbires!rcd (303)444-5710 x3086 ...Nothing left to do but smile, smile, smile.
jhodgson@sjuvax.UUCP (J. Hodgson) (10/10/86)
Since ther isn't a C standard yet, it doesn't make a lot of sense to vsay that something isn't C. After all there are some pretty bizarre things out there claiming to be Pascal, wshich does have a standard!
throopw@dg_rtp.UUCP (Wayne Throop) (10/10/86)
> rcd@nbires.UUCP (Dick Dunn) >> ? >>> ? >>> Then it isn't a C compiler... >> This is rapidly becoming one of my pet peeves. [peeves do *NOT* make good pets! :-)] > Gary's complaint is valid when people are talking about things which turn > out to be bugs - meaning something along the lines of "behavior which the > implementors agree is incorrect and should be fixed." In addition to the feeping creaturism pointed out by Dick Dunn, I note that most often Guy (and others) direct the put-down of "Then it's not a C compiler" to folks who are attempting to claim that since their compiler does X, then X is a feature of the C language. It is a pithy way of pointing out that X is a bug, not a feature. The point is that this was most often a response to somebody *denying* that a blatant bug was in fact a bug. Guy (and others) were willing to go along with this, saying in effect "OKfine, it's not a bug. But if it isn't a bug in your compiler *THEN* your compiler (really and truely) is *NOT* a C compiler". I might be persuaded that this particular putdown is somewhat overused of late, and some folks may use it inappropriately. But a guru who uses this putdown inappropriately just isn't a *C* guru! :-) -- The most deadly thing in software is the concept... that you are going to specify what you are going to do, and then do it. --- Ross in Software Engineering -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw