clifton_r@verifone.com (11/13/90)
A couple of weeks ago, I posted a draft specification of Version 7 C, which met with a mixture of enthusiasm, some hostility, and indifference. As I can't afford a heavy ego investment in this, I don't want to spend too long defending my actions. However, as some criticisms seemed to be based on a misconception of my goals, I would like to clarify my intentions. There are hundreds (thousands?) of pre-ANSI compilers out there. If you are using one, or maintaining one, there is some question as to how you can tell if it works. Assume we have such a compiler, we run a test on it, we find such-and-such behavior. Now we have to determine whether this behavior is: a) specifically required; b) preferred; c) a common behavior of a class of C compilers; d) undesirable or peculiar, but legitimate if documented; or e) a bug which must be fixed. Judging from comments I have seen on the net, there are still many non-ANSI compilers out there, so a lot of this activity is going on in many different places. Describing more of the existing practise in writing is one way to simplify this task; hence I thought I might save some people some work, at least until all of those non-ANSI compilers are superseded by ANSI compilers. > Attempting to specify a single standard for pre-ANSI C is pointless.... I don't intend to define a standard; I am sorry it appeared that way. I draw a distinction between a standard and a spec. If I may make an analogy, ANSI C is a STANDARD for unicorns - to be a unicorn, a beast must meet all of its criteria (and note that no "unicorns" existed prior to the standard.) I am trying to write a SPECIFICATION describing horses, which vary, but have been around for a long time, and can not (yet) be wished out of existence. > You would be better off to start with ANSI C and specify deletions and > modifications to it. A good point; we made a start at that approach, before giving up. The catch is that ANSI C was NOT just a more detailed specification of the existing C dialects, it defined a new form for C, with many extensions and new features. Moreover, some of the existing practises it codified match only a subset of V7 C compilers. V7 C is much closer to K&R in terms of what you can or can not count on. In my spec, I tried to spell out a number of things you can NOT count on, or which might work several ways, and to suggest that any individual compiler's documentation should specifically state how IT works. > People who have to use a wide variety of earlier compilers tend to use > H&S as a basic reference. So do I - you DID look at the references? However, H&S describes a much broader range of compilers than most programmers may actually work with. Many older compilers actually describe themselves as "V7 C" compatible; it's just that it appears no one has ever sat down and tried to spell it out. I don't believe in make-work -- before trying to write this, folks at our company spent quite a while trying to find a document which did cover the "standard V7" features, like "void", "enum", etc. (Including a request to several net news groups.) No luck; it's been one of those things that "everyone knows what it is, but nobody can tell you." (Like obscenity?) > Implementors are aiming at ANSI C, which is well documented. Agreed. Sometime in the next year, I hope our company will support ANSI C too. In the meantime, I am disinclined to leave our existing C compiler inadequately documented or insufficiently tested, even if our DQ department would let me. Likewise, I hope other vendors of non-ANSI compilers have not yet terminated all maintenance and documentation for their compilers.... > 'signed char' is particularly odd... Yes, I must have been especially brain damaged that day; it's not even in OUR compiler. I have now deleted all references to the 'signed' keyword. > 'void' [and] 'unsigned char'.... None of these things were in V7 C... I have now clarified this, thanks to some helpful responses. Several key features, including 'void', 'unsigned char', and separate name spaces for structure types were in Johnson's PCC, but not in Ritchie's C compiler for V7. Since I don't want to say the official C compiler for UNIX V7 on the PDP-11 was not V7 C, I have footnoted the distinction in my document. Many subsequent C compilers have been derived from or modelled after PCC, and that is probably the significant line of descent. > Please don't try to fob off the peculiar specs of your own pet compiler > as a standard. I certainly have been influenced by the compilers I have access to, but if I were interested only in my own compiler, I wouldn't try to define a whole range of different acceptable behaviors in some areas. I thought this might be useful to other compiler maintenance and documentation people. As noted above, I have goofed in some respects and am trying to correct them. If you don't like my spec (NOT my "standard"), please ignore it. > ... fix your compiler to the standard we already have. You can't "fix" a V7 C compiler to be a quality ANSI C compiler, because the changes are major; they implement different languages in some key respects. You can re-engineer it; i.e. design an ANSI compiler and re-use a lot of the older compiler code. Would most compiler writers agree this is a major and lengthy task? If not, why are most commercial vendors taking so long? -- A large number of the world's most experienced experts ... have finally -- produced the first genuine, officially sanctioned standard for C; use it -- and be happy. But I won't be very happy if I use it as a spec for a non-ANSI compiler, will I? Nor will the users. If I were starting out to implement a new compiler, I would make it full ANSI, but as noted, there are a lot of older compilers out there, and we can't just drop them instantly. -- Anyone who thinks that he can do better working on his own must be -- woefully ignorant of the issues involved. -- There were three extensive public reviews of the draft proposed C -- standard, leading to numerous improvements in the final version. I don't have a budget like ANSI, nor do I have dozens of member companies to help in the definition, but I thought posting to the net MIGHT bring some more minds to bear, and put me in touch with some C experts, which it did. I _am_ thankful for the various tips and corrections I received. Thanks to: Henry Spencer, Doug Gwynn, Gordon Burdett, Ceriel Jacobs (in Amsterdam), and to Rahul Dhesi and Colin Plumb for moral support. I was somewhat disappointed by the hostile and superior attitudes a few responses expressed, and their assumption that my efforts must be due either to ignorance or to arrogance. At least I was not accused of software piracy or cheating on my homework, as a few hapless souls have been. Ah well. I promise to take future criticisms with a smile, and without further feeble attempts at self-defense. -- Clifton
rfg@NCD.COM (Ron Guilmette) (11/16/90)
In article <2451.273eb16b@verifone.com> clifton_r@verifone.com writes:
+A couple of weeks ago, I posted a draft specification of Version 7 C, which
+met with a mixture of enthusiasm, some hostility, and indifference. As I
+can't afford a heavy ego investment in this, I don't want to spend too long
+defending my actions. However, as some criticisms seemed to be based on a
+misconception of my goals, I would like to clarify my intentions.
+
...
+I don't intend to define a standard; I am sorry it appeared that way. I draw
+a distinction between a standard and a spec...
That's just a smokescreen. A cow-patty by any other name would smell the
same.
This group is for discussing the use of (and the rules of) ANSI C. If you
sense some hostility, it is probably because the people who read and write
this group mostly want to see people starting using (and conforming to)
the One and Only approved standard for the language C.
Talking about non-conforming (decrepit and anachronistic) implementations
of the C language does not help to promote that goal. Proposing
ad-hoc standards for non-conforming (pre-ANSI) implementations actively
pushes people away from that goal.
Perhaps you need a group of your own called comp.lang.anachronistic-c.
--
// Ron Guilmette - C++ Entomologist
// Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg
// Motto: If it sticks, force it. If it breaks, it needed replacing anyway.