Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c
Subject: Noalias (was Re: unofficial X3J11 meeting notes)
Keywords: ANSI C standard
Message-ID: <3297@ulysses.homer.nj.att.com>
Date: 15 Dec 87 21:58:18 GMT
References: <6829@brl-smoke.ARPA> <9753@mimsy.UUCP> <6830@brl-smoke.ARPA> <9770@mimsy.UUCP> <6833@brl-smoke.ARPA>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: jss@hector (Jerry Schwarz)
Organization: AT&T Bell Labs, Murray Hill
Lines: 66

In article <6833@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes:
>
>The "noalias" type qualifier promises that the object can only be
>modified by a single handle (as I said), thereby permitting the
>optimizer to do things that are not safe otherwise; for example,
>for pointers that could be used as aliases accessing the same
>object, without "noalias" qualifying the object, every time it
>was modified via one pointer the compiler would have to assume
>that the modification might affect what is seen via the other
>pointer.  

My gut reaction is that this is a bad idea, but I'm withholding
final judgement until I see the exact wording of the proposal.

The original description suggested that the English constraints
about overlapping strings in functions like "strcpy" could
be replaced by the use of "noalias" in their declarations.
I think this is doubtful because "noalias" is either too
strong or two weak.

Consider  strcpy(s1,s2) 

	If the redeclaration means that s1 and s2 can't point to the
	same char then it is too weak.  The strings could still
	overlap even if they have different initial chars.

	If it means that they can't point into the same array then
	it is too strong because the strings might be known to
	be disjoint, even though they are part of the same array.

Is 
	strcpy((char*)&errno,"a")

allowed?  It depends on whether the body of strcpy refers to errno.
Thus in place of the English requiring disjointness of the arguments
I need something to tell me what globals strcpy refers to.

>Fortunately, the typical programmer can just ignore it and
>never use "noalias" in his code, so it only affects those who
>like to fine-tune things.

But the headaches for maintainance of programs containing "noalias"
are likely to be enormous.  Every time I make even a minor change to
such a program I have to be aware of the implications for pointers
that I might not even be aware of.  For example, if I assign to or
use a global variable in a function that was not mentioned in the
function before my change, I have to know that there is no caller
anywhere who has stuffed the address of that variable into a
"noalias" pointer.

I can imagine some reasonable uses of "noalias".  The first
corresponds to "register" in that it would prohibit taking the
address of a top level identifier.  (I initially wrote "global
variable", but then I realized that a compiler might be able to make
good use a the information that a particular function is always
called directly.) Another use might be in a structure member to
indicate that addresses are never taken on that component.   What
these have in common is that they are enforceable by the compiler.

Jerry Schwarz
Bell Labs

P.S.  Normally I would wait to see exactly what was being proposed
before rushing to judgement, but I suspect that the time constraints
here are such that final action on the proposal will occur before I
see its details.