Path: utzoo!mnetor!uunet!husc6!yale!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Wording concerning noalias
Message-ID: <7072@brl-smoke.ARPA>
Date: 13 Jan 88 07:49:46 GMT
References: <10155@mimsy.UUCP>
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 144

In article <10155@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> >I wish I knew for sure what noalias meant.
> So do I---it is hard to argue against something when no one will say
> exactly what that something is :-) . . . .

Ok, here is one TENTATIVE proposal for the aliasing wording to appear
in the second public review draft proposed C standard, borrowed without
permission from the people working on the words (I was supposed to be
one of them, but I got sick and missed the meeting).  If you find
actual technical errors, please mail them to me and I'll forward them
to the appropriate people, who probably don't want to have to discuss
this directly with the "public" at this time.  Keep in mind that there
is no guarantee that this is what will actually be in the standard,
but it is the first (and only, so far) proposed draft wording about
this issue that I've seen.  This posting is entirely unofficial, and I
hope the X3J11 members working on this don't get too angry with me for
prematurely spilling the beans.  However, I think it may clear up some
misunderstandings caused by my previous vague descriptions of what
"noalias" is all about.  In any case, it should establish some useful
terminology for discussing the issue.

'\" This is in "troff -mm" input format, using three additional macros:
'\" The "Cf" macro prints its argument in constant-width font.
'\" "Cb" and "Ce" delimit a constant-width display.
'\"
'\" Sample definitions for these macros:
.de Cf
\&\\f(CW\\$1\\fP
..
.de Cb
.DS
.ft CW
..
.de Ce
.ft
.DE
..
'\"
.P
Each lvalue that is a unary expression with the unary
.Cf *
indirection operator
(either explicitly
or as a result of the array subscript
.Cf []
operator)
contains one or more
.IR handles ,
the smallest expressions with pointer or array type
associated with the entire object
of which the object referred to by the lvalue
is all or a part thereof,
ignoring the left operand of the comma operator,
the operand of the
.Cf sizeof
operator,
all argument expressions,
and all expressions with integral type.
The handles for lvalues with noalias-qualified type are
.IR "noalias handles" .
A handle is distinguished by the spelling of its operands
and by the storage duration of the objects
whose values are accessed to evaluate the handle
(the
.IR "handle objects" ).
.P
For each distinct noalias handle,
it is unspecified whether the handle is associated
with the entire object of which a part is designated
by the otherwise identical handle of an lvalue
that has the non-noalias-qualified version of the type
(the
.IR "actual object" )
or is associated with a distinct object
(a
.IR "virtual object" )
with the same size and address as the actual object.
The behavior of a program that depends upon
a specific implementation choice is undefined.
.P
A virtual object,
if and when created,
acquires the last-stored value of the actual object.
A virtual object may be created at any sequence point
of a function for which there exists a sequence point
at which the storage for all handle objects
is guaranteed to be reserved.
A virtual object has a
.IR "pending value"
if it has been modified through use of
its noalias handle and the actual object does not
have the same value.
All virtual objects with pending values for a noalias handle
have their values assigned to their respective actual objects
between the last sequence point before which
the storage is no longer guaranteed to be reserved
for a handle object of the noalias handle,
and the function return.
.P
For each distinct noalias handle,
it is unspecified whether the handle is associated
with the entire object of which a part is designated
by the otherwise identical handle of an lvalue
that has the non-noalias-qualified version of the type
(the
.IR "actual object" )
or is associated with a distinct object
(a
.IR "virtual object" )
with the same size and address as the actual object.
The behavior of a program that depends upon
a specific implementation choice is undefined.
.P
A virtual object,
if and when created,
acquires the last-stored value of the actual object.
A virtual object may be created at any sequence point
of a function for which there exists a sequence point
at which the storage for all handle objects
is guaranteed to be reserved.
A virtual object has a
.IR "pending value"
if it has been modified through use of
its noalias handle and the actual object does not
have the same value.
All virtual objects with pending values for a noalias handle
have their values assigned to their respective actual objects
between the last sequence point before which
the storage is no longer guaranteed to be reserved
for a handle object of the noalias handle,
and the function return.
.P
The following are examples of some lvalues and their handles:
.Cb
	int a[2], b[3][4], i;
	int *p, *f();

	a[1];        /* \fIsame as \fP*(a + 1)\fI, handle: \fPa */
	b[i][2];     /* \fIsame as \fP*(b[i] + 2)\fI, handle: \fPb */
	*p;          /* \fIhandle: \fPp */
	*(p + i);    /* \fIhandle: \fPp */
	*(i = 4, p); /* \fIhandle: \fPp */
	*f();        /* \fIhandle: \fPf() */
.Ce