[comp.lang.c] Rationale for my posting draft V7 C description

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.

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/16/90)

In article <2713@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
> This group is for discussing the use of (and the rules of) ANSI C.

No. It is for discussions of C. ANSI C is only a small but growing
corner of C.

---Dan

goudreau@dg-rtp.dg.com (Bob Goudreau) (11/17/90)

In article <19347:Nov1608:11:3390@kramden.acf.nyu.edu>,
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> In article <2713@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
> > This group is for discussing the use of (and the rules of) ANSI C.
> 
> No. It is for discussions of C. ANSI C is only a small but growing
> corner of C.

No.  He was talking about the cross-posting of this discussion to
comp.std.c, which certainly *is* dedicated to ANSI C.   You did notice
that the original guy had listed comp.std.c as well as comp.lang.c
in his "Newsgroups" line, didn't you?

----------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA

peter@ficc.ferranti.com (Peter da Silva) (11/20/90)

In article <2713@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
[ in the middle of a bunch of flames ]
> 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.

That's nice, but out here in the real world I don't ever expect to
see a real ANSI C compiler for the 40 or so pre-SCO Xenix-286 boxes we're
having to use (mainly, because iNTEL refuses to support PL/M on UNIX and
we've got a large investment in PL/M code).

For the next few years at least it will remain necessary to support K&R
compilers, and to write code so it won't break them. This means a lot of
ifdef __STDC__, and it helps to have a reasonable description of the state
of the art. I was glad to see it... though I don't need it personally I'm
not the only C coder here...

> // Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

Sorry, we don't have replacement parts in stock.

If you want to *help* the situation, write a deprotoiser that fixes up all
the calls... that is, if you have:

	extern void foo(float bar);

	...
		foo(3.0);
		foo(2);

It converts this to:

	extern foo();

	...
		(void)foo((float)3.0);
		(void)foo((float)2);

Otherwise people are going to have to keep coding in two languages.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com 

zvs@bby.oz.au (Zev Sero) (11/20/90)

Ron = rfg@NCD.COM (Ron Guilmette)

Ron> That's just a smokescreen.  A cow-patty by any other name would smell the
Ron> same.

I'd hope that cow patties don't smell the same as cow pats!  Perhaps
you are referring to McDonald's cow patties, which I am informed are
merely cow pats with tomato sauce.
---
                                Zev Sero  -  zvs@bby.oz.au
As I recall, zero was invented by Arabic mathematicians
thousands of years ago.  It's a pity it still frightens
or confuses people.           - Doug Gwyn

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/20/90)

In article <1990Nov17.004557.14642@dg-rtp.dg.com> goudreau@dg-rtp.dg.com (Bob Goudreau) writes:
> In article <19347:Nov1608:11:3390@kramden.acf.nyu.edu>,
> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> > In article <2713@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
> > > This group is for discussing the use of (and the rules of) ANSI C.
> > No. It is for discussions of C. ANSI C is only a small but growing
> > corner of C.
> No.  He was talking about the cross-posting of this discussion to
> comp.std.c, which certainly *is* dedicated to ANSI C.   You did notice
> that the original guy had listed comp.std.c as well as comp.lang.c
> in his "Newsgroups" line, didn't you?

No, I didn't. If Ron hadn't thought that his comments were appropriate
for comp.lang.c, why would he have set followups to this group? There's
no reason I should have looked at the original newsgroups.

---Dan

goudreau@dg-rtp.dg.com (Bob Goudreau) (11/21/90)

In article <9770:Nov2004:40:4490@kramden.acf.nyu.edu>,
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> 
> > No.  He was talking about the cross-posting of this discussion to
> > comp.std.c, which certainly *is* dedicated to ANSI C.   You did
notice
> > that the original guy had listed comp.std.c as well as comp.lang.c
> > in his "Newsgroups" line, didn't you?
> 
> No, I didn't. If Ron hadn't thought that his comments were
appropriate
> for comp.lang.c, why would he have set followups to this group?

Geez, that was exactly the point:  to move the discussion *out* of
comp.std.c (where it didn't belong) and into comp.lang.c (where it
is appropriate).


> There's no reason I should have looked at the original newsgroups.

There's no excuse for not paying attention to *all* the contents
of an article, including its header.

----------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/22/90)

No technical content.

In article <1990Nov20.173322.18533@dg-rtp.dg.com> goudreau@dg-rtp.dg.com (Bob Goudreau) writes:
> In article <9770:Nov2004:40:4490@kramden.acf.nyu.edu>,
> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> > > No.  He was talking about the cross-posting of this discussion to
> > > comp.std.c, which certainly *is* dedicated to ANSI C.   You did notice
> > > that the original guy had listed comp.std.c as well as comp.lang.c
> > > in his "Newsgroups" line, didn't you?
> > No, I didn't. If Ron hadn't thought that his comments were appropriate
> > for comp.lang.c, why would he have set followups to this group?
> Geez, that was exactly the point:  to move the discussion *out* of
> comp.std.c (where it didn't belong) and into comp.lang.c (where it
> is appropriate).

That's exactly my point. He was moving the discussion into comp.lang.c,
so his comments about ``this thread is inappropriate for this group''
applied to comp.lang.c. And that's what I disagreed with.

The article was cross-posted to comp.lang.c and comp.std.c, with
followups to the former. Obviously the poster thought the subject of the
article belonged in comp.lang.c. The subject of the article was the
claim that ``X is inappropriate for this group.'' How can ``this group''
apply to anything but comp.lang.c?

> > There's no reason I should have looked at the original newsgroups.
> There's no excuse for not paying attention to *all* the contents
> of an article, including its header.

Really? I don't spend time thinking about the Path unless I care what
path the article took. I don't spend time thinking about the Newsgroups
unless I care what the original newsgroups were. I usually accept the
last poster's judgment about where a discussion belongs; if he thinks it
belongs in comp.lang.c, and then refers to ``this group'' without
further qualification or explanation, why shouldn't I assume he's
referring to comp.lang.c?

---Dan

goudreau@gotham.rtp.dg.com (Bob Goudreau) (11/22/90)

In article <26008:Nov2119:38:1890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>> Geez, that was exactly the point:  to move the discussion *out* of
>> comp.std.c (where it didn't belong) and into comp.lang.c (where it
>> is appropriate).
>
>That's exactly my point. He was moving the discussion into comp.lang.c,
>so his comments about ``this thread is inappropriate for this group''
>applied to comp.lang.c.

No, that's exactly backwards.  I think I now understand your
confusion.  His "this group" comment did not apply to comp.lang.c,
but to comp.std.c.  See below.

>The article was cross-posted to comp.lang.c and comp.std.c, with
>followups to the former. Obviously the poster thought the subject of the
>article belonged in comp.lang.c. The subject of the article was the
>claim that ``X is inappropriate for this group.'' How can ``this group''
>apply to anything but comp.lang.c?

Here's what happened:

1)  Some person started this discussion by posting to *both*
    comp.lang.c and comp.std.c.

2)  The guy I'm defending posted a followup (thus posted to both
    newsgroups of the original) article wherein he advocated getting
    the discussion *out* of comp.std.c, and leaving it only in
    comp.lang.c.  To this end, he added "Followup-To: comp.lang.c.".
    The only miscue was that he didn't make it eminently clear that
    his use of "this" referred to .std.c and not to .lang.c.  Careful
    readers were able to figure this out.


>> > There's no reason I should have looked at the original newsgroups.
>> There's no excuse for not paying attention to *all* the contents
>> of an article, including its header.
>
>Really? I don't spend time thinking about the Path unless I care what
>path the article took. I don't spend time thinking about the Newsgroups
>unless I care what the original newsgroups were.

The "Newsroups" field doesn't tell you what the original groups were;
it just tells you to which newsgroups the current article was posted.
Bear in mind that you may be reading only one of multiple groups that
saw the message.

>I usually accept the
>last poster's judgment about where a discussion belongs; if he thinks it
>belongs in comp.lang.c, and then refers to ``this group'' without
>further qualification or explanation, why shouldn't I assume he's
>referring to comp.lang.c?

I agree that he blew it as far as removing all possible ambiguity;
he could have helped the situation out by saying something like
"this discussion doesn't belong in the comp.std.c newsgroup" instead
of just "this doesn't belong in this group" and having the reader
figure out (and honest, it wasn't hard; I was able to do it!) from
the context which of the two posted-to groups he meant.  But heck,
that's why it *is* a good idea to look at the headers.  Just like it's
a good idea to look at mail headers, to be able to distinguish between
mail that was sent "To:" you from mail that was merely "Cc:"-ed to you,
or mail that was "Bcc:"-ed to you.  That header information can make
all the difference in the world when you receive mail containing the
word "you", for instance; it lets you know who "you" is.

----------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau@dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/28/90)

Let's move this thread from comp.lang.c to this group.

In article <1990Nov22.064411.24247@dg-rtp.dg.com> goudreau@gotham.rtp.dg.com (Bob Goudreau) writes:
> >I usually accept the
> >last poster's judgment about where a discussion belongs; if he thinks it
> >belongs in comp.lang.c, and then refers to ``this group'' without
> >further qualification or explanation, why shouldn't I assume he's
> >referring to comp.lang.c?
> I agree that he blew it as far as removing all possible ambiguity;

It's not a question of ambiguity. To me, ``this group'' above refers
unambiguously to alt.religion.computers, even though people in
comp.lang.c also see the article. This is how lots of other people use
the term. Of course, everyone in the minority who believe otherwise is
going to send a reply to this group saying how ``this group'' really is
ambiguous.

(Why is the majority right? Because in the default case, ``this group''
refers unambiguously to the single group where followups go. Apply
Occam's Razor to see that whenever followups go to a single group,
``this group'' must refer unambiguously to that group.%)

> he could have helped the situation out by saying something like
> "this discussion doesn't belong in the comp.std.c newsgroup" instead
> of just "this doesn't belong in this group" and having the reader
> figure out (and honest, it wasn't hard; I was able to do it!) from
> the context which of the two posted-to groups he meant.  But heck,
> that's why it *is* a good idea to look at the headers.

I addressed this argument before. Why should I waste time looking at
every header on every article just to accommodate a small number of
people who can't speak straight? Writing is the job of giving thoughts
to the reader. If you believe that most readers interpret ``this group''
as being ambiguous for a crossposted article with followups to a single
group, then you're failing your responsibility as a writer whenever you
use the phrase. There are thousands of readers, and they all have a
perfect right to assume that the writer has followed their default
assumptions.

> Just like it's
> a good idea to look at mail headers, to be able to distinguish between
> mail that was sent "To:" you from mail that was merely "Cc:"-ed to you,
> or mail that was "Bcc:"-ed to you.  That header information can make
> all the difference in the world when you receive mail containing the
> word "you", for instance; it lets you know who "you" is.

Perfect analogy! If my reply to a message goes to just one person plus
me, then I know ``you'' refers to me, and ``I'' refers to that person.
Similarly, if my followup to an article goes to just one group, then I
know ``this group'' refers to that group. That's how things work in the
default case; writers who disobey the conventions without explicitly
warning the reader are just asking for trouble. It's not the reader's
responsibility to detect the mistake.

---Dan

% It's also true that in the default case, ``this group'' refers to the
single newsgroup where the article was originally posted. So if the
article was originally posted to a single newsgroup, then ``this group''
must refer to that group. But if followups go to a single newsgroup,
then ``this group'' must, as we already know, refer to that group!
Therefore ``this group'' is ambiguous for an article that starts in a
single group and has followups to a single group. There you have it, a
metaphysical argument for making sure that Newsgroups: always includes
all the groups in Followup-To:.