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.