Rationale for my posting draft V7 C description

[clifton_r at verifone.com]

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