Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: some objections to 'noalias'
Message-ID: <485@cresswell.quintus.UUCP>
Date: 21 Dec 87 10:24:30 GMT
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 102
Keywords: lines=106, pragmas, compiler hints

'register' is a promise to the compiler: "I faithfully promise
	not to take the address of this, and if that helps you,
	fine."  This is something the compiler can verify, and
	if you break your promise the compiler can and should
	warn you.

'const' is a promise to the compiler: "I faithfully promise
	not to store through THIS path, and if that helps you,
	fine."  This is something the compiler can verify, and
	if you break your promise the compiler can and should
	warn you.  This is a positive help to programmers, as
	if you don't intend to change a parameter, you should
	declare it const, and the compiler will warn you about
	a mistaken change (the only known way of catching the
	writing-"="-instead-of-"==" bug).
	
'volatile' is a warning to the compiler: "watch out, this thing
	may change at any time".  The compiler cannot verify
	this, but it is safe for the compiler to believe you;
	the worst that can happen is loss of speed.

'noalias', however, is a promise to the compiler which the
	compiler cannot check, which it is NOT safe for the
	compiler to take on faith.

So we have two problems with "noalias"
(1) "noalias" does NOT mean "no alias", as Doug Gwyn showed in
    an example.  It means something like "there may be any number of
    aliases for this thing, one of which has the noalias property,
    and some of which, due to casting, have not, but changes will
    only be done through the version having the noalias property,
    so the compiler may rely on that version not changing
    unexpectedly."  Whatever the exact rule is, it is something
    quite different from and more complex than a simple "no aliases"
    rule, so the name is misleading.

(2) Believing the programmer is not a safe approximation.
    Judging from some of the examples so far, the intended property
    may not be computable.

Having some way of telling a compiler that something has no aliases
sounds like a really good idea.  (Euclid did this by making all
aliasing illegal.  One of the reasons for having storage pools
explicit in that language was so that a compiler could tell that
two pointers to different pools couldn't possibly be aliases.)  But
the right way to do this is to come up with some property which the
compiler (or a separate checker) can verify, and which implies the
property of interest.  This is a non-trivial task in language
design, especially in the case of C.  Rushing it in at the last
minute is not a good idea.

(3) A snag with things like volatile and noalias is that they
clutter up the language.  There are a great many things that one
might want to tell a compiler.  There should be one generic
mechanism for all of them.  The simplest scheme I can think of
is to replace the rule

	type_qualifier : CONST | VOLATILE ;

by	type_qualifier : CONST | PRAGMA '(' praginfo ')' ;

	praginfo : /* empty */ | praginfo primary_expr ;

so that one could declare
	extern pragma(volatile)
	struct device tty_device;
or
	static pragma(signal_handler)
	void my_sigfpe_handler(...) { ... }

or whatever.  The definition of 'praginfo' was carefully designed
so that
	#define pragma(x)
could be used in a compiler which didn't yet understand pragma(),
but in general a compiler would accept some pragmas and warn about
the others.  This approach takes one reserved word in the language,
but imposes no bound on the number of hints you can give the compiler.

If the FORTRAN committee have not found a need to introduce a 'noalias'
mechanism into that language (aliasing is quite possible in FORTRAN),
what makes C so special?  I have seen the February '87 draft of the
FORTRAN 8X (they'd better hurry) standard.  That's getting to be a
very complicated language indeed (user-defined types, with parameters
yet!) but they still hadn't put 'noalias' in.

The approach taken by the majority of other programming languages is
that if you change one alias of a location and then access it via
another location it's your own silly fault if you don't get the
answer you expected.  I can't think of any of my own C programs
where it would not have been appropriate to declare ALL variables
'noalias'.  So that's a fourth problem with noalias: it's back to front.

Why not simply say that the compiler is entitled to assume 'noalias'
for everything, and that if the programmer wants unsafe aliases s/he
should declare the variables in question to be 'volatile'?  Doesn't
"volatile" mean that a variable may change behind the compiler's
back, and isn't that exactly what we want here?

This might perhaps be a "Quiet Change", but nobody ever told me that
aliasing was supposed to be legal in C, so even that isn't clear.
I don't see why having noalias as the basic assumption should be any
more of a burden on me in C than it is in FORTRAN.