Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c,net.unix-wizards
Subject: Re: summary of C-standards workshop at Usenix
Message-ID: <4050@utzoo.UUCP>
Date: Mon, 9-Jul-84 19:00:11 EDT
Article-I.D.: utzoo.4050
Posted: Mon Jul  9 19:00:11 1984
Date-Received: Mon, 9-Jul-84 19:00:11 EDT
References: <4013@utzoo.UUCP>, <1128@utah-gr.UUCP>, <274@lvbull.UUCP>
Organization: U of Toronto Zoology
Lines: 54

In reply to some comments from Pete Delaney...

    Const being a sub-type may be reasonable; my first thought was that
    it should be a sub-storage class.  I find the syntax awkward.

Making const a storage class strikes everyone as the obvious thing to do
at first.  It has problems in that it really does need to be a sub-class,
since "static" and "extern" are still reasonable modifiers even for const
data.  It also greatly limits the versatility of const -- most of the
examples I gave in my summary were things you couldn't write if const were
a storage class.  My own personal view is that the real, crying need is
for a way to say "put this in read-only memory", and a (sub-)storage class
probably would have sufficed for that, but I have nothing serious against
the more sophisticated facility.  It does have its advantages.

And you aren't the only one who doesn't like the syntax!  I haven't got any
decisively better ideas, though.

    I thing long global ID's are reasonable.

Me too.  But I don't see any way to compel the whole world to conform to
this belief, and until they do, the problem isn't fixable.

    Why do we need void *, the 'universital pointer', the syntax is
    questionable?

The use of "void *" as the universal-pointer syntax is a blatant concession
to not wanting to introduce unnecessary new keywords, for fear of breaking
too many old programs.  It's distasteful but bearable.  The need for the
universal pointer is mostly in connection with storage management:  what
type does "malloc" return?  Making "char *" the universal pointer does
cause problems, not least among them the inefficiency of handling "char *"
on some architectures.  And there's no way to shut lint up about malloc,
either, because lint has no way to know that the "char *" which malloc is
returning is acceptable for casting to other types, unlike some "char *"s.

    What do K&R think of this stuff; I think they should be given substantial
    control as to the direction of THEIR language.

Dennis Ritchie is well aware of what the ANSI folks are doing.  They consult
him with some frequency.  He was at the Usenix session, and commented on
a few things ("enums are a botch").  My impression is that he's cautiously
in favor of most of what they are doing, with reservations about a few
problems.  [Note that this is my impression only.]

    Question the utility of standards commitiees.

Standards are a practical necessity, I'm afraid; the language has gone far
beyond the point where Dennis could maintain personal control over it, even
if he really wanted the headaches that would ensue.  And the politics of
standards development require committees, alas.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry