Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.lang.c
Subject: Noalias considered unreadable, let alone a bad idea
Message-ID: <3932@hoptoad.uucp>
Date: 25 Jan 88 16:52:51 GMT
References: <7072@brl-smoke.ARPA> <7160@brl-smoke.ARPA>
Organization: Nebula Consultants in San Francisco
Lines: 78

I too have read the 'Revised "noalias" words' from Dave Prosser, and
still think it's a bad idea.  While there might be a place in ANSI C
for things that can't be explained clearly in a paragraph, there should
be no place for things that can't be explained clearly in a page.
And no place at all for things where the three people who claim to
understand it are unable to explain it, over a protracted period,
to the rest of us.  (Or are those three people going to write *all*
the ANSI C compilers?)

In particular, the words used do not make clear what the difference is
between a "virtual object" and an "actual object", nor do they describe
how C operators (such as =, *, or +) operate differently on virtual
objects versus actual objects.  It also seems to be confused between
lvalues and handles -- or maybe I am.  It spends most of a page telling
us that the handles in an expression come from the identifiers that are
in the expression.  It seems to indicate that the handle in the lvalue
*(foo = x)  is from foo, not from x.  (It might be right!)  It says that
pending values must be synchronized when "the storage of the object
declared by the noalias handle" is not guaranteed to exist any more.
However, neither handles nor lvalues ever declare objects.  It seems to
imply that not only can a given real object have multiple virtual
objects associated with it, but a single *handle* to a real object can
end up having several virtual objects, some of which might have pending
stores and thus different values ("If one or more of the virtual
objects of a noalias handle...").  How it decides which one to give you
when you reference the lvalue that started all this is problematic at
best.  The whole definition seems to be tied to function calls as a
kind of sequence point that is "more important" than other sequence
points; in fact, the only things required by the whole three pages
occur at function calls and returns (the rest is all optional).  And
"The behavior of a program that depends on a specific implementation
choice [of virtual versus actual objects] is undefined"...if they
thought this sentence made it clear that strcpy() of overlapping areas
in the same array is "undefined", but nonoverlapping areas in the same
array is "defined", I wish they would explain just how.

I could go on but it should be clear that the wording is
incomprehensible.  If you thought the standard was unreadable before,
this is a step in the wrong direction.

I think if Cray or somebody wants to vectorize C, they should make a
nonstandard version of C and try it for a few years, not mangle our
almost-standard with this kind of unexplored randomness.

Here's an interesting exchange between Richard Stallman, who had to
understand the draft standard to implement it, and Dave Prosser, who
seems to be editing it.  They were discussing a problem that I
encountered where the shiny new ANSI CPP rules about recursive macro
definitions broke some useful, existing code that nests macro names in
arguments to other macros and expands them inside by putting
parentheses and arguments after them.  This worked in 90% of the
cases but one particular combination made it fail.  (What broke was Sun's
latest RasterOp implementation, BTW, quite an impressive piece of work.)

RMS:
> Why don't you pass the problem on to your friends on the committee?
> At least you can enjoy their consternation.
> 
> On second thought, please don't.  The current spec may not be clean,
> but at least it was implementable.  Who knows what they would come up
> with next?

Dave:
> I don't know in what spirit the last paragraph was intended, but
> thanks for the humor.  At least you see that the current specification
> can be implemented without real problems.  I seem to regularly handle
> calls trying to understand the current draft and complaints that it
> is totally unimplementable!  I guess I'll save this concern for a
> rainy day, or a inspiration...

RMS:
> Having implemented the current draft, I agree nearly completely with those
> callers.  It is not impossible to implement, but it is difficult,
> and it is very difficult to figure out exactly what is to be implemented.
> I'm not surprised people think it is unimplementable.
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
		"Watch me change my world..." -- Liquid Theatre