Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William E. Sommerfeld)
Newsgroups: comp.lang.c
Subject: Re: alias/noalias etc. (long, really)
Message-ID: <2235@bloom-beacon.MIT.EDU>
Date: 11 Jan 88 17:38:36 GMT
References: <11189@brl-adm.ARPA> <517@cresswell.quintus.UUCP> <5772@sol.ARPA>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William E. Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 66

In article <5772@sol.ARPA> quiroz@ROCHESTER.UUCP (Cesar Quiroz) writes:
>[Disclaimer: The gross flashback to Fortran is on intention, so no
>one believes I am proposing *this syntax*.  This is just an
>example.]  The idea is to permit the compiler to do something
>interesting in the scope where this is safe.  We are saying in fact
>"Dear Compiler: if it helps you, be aware of such and such
>interaction or lack thereof for the following expressions."  It
>doesn't say more, so if an optimization depends on, for example,
>`this' not having aliases in that scope, then our hint won't be
>powerful enough to permit the optimization.  Indeed, the example
>above might not be too fruitful in optimizations anyway, but you get
>the idea.

This is more of an idea of `how to give hints to optimizers' than
`what should be done to c'...

It might be reasonable to use something like `assert' for this; it
would be different from the `normal' assert (which aborts if the
condition is false);

To reuse his example, the last section could be written as:

        {                      /* Deal with full-formed list */
            for (this = link, next = link -> next; 
		 next; 
		 this = next; next = next -> link) {
                assert(this != next);
		assert(this != NULL); 
		/* body which does operations on *this and *next */
            }
            /* `this' and `next' may point to the same object here! */
        }

This has the advantage that it can be handled two ways: when debugging
and testing, it can be used to check for program bugs, and when
running in `production' mode, the assert can be used by the optimizer
to make assumptions about things (that storing through `this' will not
affect things fetched through `next').

It seems more important to include assertions about arguments to
functions and their return values along the lines of:

extern char *strcpy (char * to, const char * from) 
	assert (to != NULL && from != NULL && strcpy() == to);

extern void *malloc (long length) assert (length > 0);
extern void *xmalloc (long length) assert (length > 0 && xmalloc() != NULL);
extern blackhole abort ();

it might make for both better-optimized _and_ more correct programs,
since the declarations can also be checked against the source to the
routines themselves; 

Given the above declarations (and assuming that `s' was not null), the
compiler (or an extended "lint") could justifiably complain about:

	strcpy((char *)malloc(strlen(s)+1), s);

(since the first argument could be NULL), whereas it would not
complain about:

	if ((temp = malloc (strlen (s) + 1)) == NULL)
		abort();
	strcpy(temp, s);
or
	strcpy (xmalloc (strlen(s)+1), s);