Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
From: TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU
Newsgroups: comp.lang.c
Subject: Hey buddy, pick on a keyword your own size!
Message-ID: <10972@brl-adm.ARPA>
Date: 23 Dec 87 07:43:40 GMT
Sender: news@brl-adm.ARPA
Lines: 54

I can't believe what I am reading.

First of all, mmdengl@cuuxb.ATT.COM on 22-Dec-87 did the best job
so far de-confusing the whole noalias situation.

Let me try to state more clearly what I said before.

Currently, K&R (and every compiler you've used so far) has been
forced to assume (for safety) that your variables are NOT NOALIAS
(i.e. they ARE assumed ALIASED).

All ANSI is saying is that there should be a way for a programmer
to point out to the compiler that, "Hey, this is a safe variable...
let your optimizer have a field day."

(for this next paragraph, flame directly to me TLIMONCE@DREW.bitnet):
(It's a bit blunt... or should I say "rude"?):
If you don't understand the purpose of noalias then ignore it.
It won't effect you.  If you do understand it, use it.

Someone asked, "Why not use violate?"  Good question.  Violate implies
that it is a IO location (i.e. memory mapped).  If you have a pointer
to a violate int, that may be pointed to a constant memory location who's
value is (ummm... think of a good example... ummm) the status of a serial
port.  noalias implies that the location will change due to pointers.

Arrrgh!  We're wasting all this time talking about something that doesn't
affect you unless you are a compiler writer!  Programmers should say,
"noalias?  Nice little keyword, maybe I'll use it if I need to
someday."  Compiler writers should be saying, "noalias?  Doesn't bother
me!" or "Good, now I can do a new-and-funky optimizer."

Not only can the programmer just plain ignore it if s/he doesn't want to
use it, a compiler writer can "ignore" it and generate code as usual.
Just like "register", many don't use it and many compilers ignore it.
(Ummm, ignore it for different reasons that noalias though).

As far as a new method for pragmas, someone suggested allowing:
          int (pragma-this, pragma-that) *i;
That's interesting, but talk about "extreme modifications to C".  Let's
not make C another pascal or fortran.  This is something that a compiler
writer may want to add so that Standard II will include it as prior art.
I would group all those (violate, register, const, noalias, etc) into
allowing this as well as making it a standard platform for other ideas.
Maybe a clause that allows the compiler to just warn about unrecognized
options in this situation like a pragma.  But let's leave this for the
next standard.

                    Tom Limoncelli
                    tlimonce@drew.BITNET

Disclaimer:  If you believe a word I say it's a miracle.  ASCII subliminal
messages haven't been invented yet.
--------------------------------------------------------------------------