Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Noalias (was Re: unofficial X3J11 meeting notes) Keywords: ANSI C standard Message-ID: <6849@brl-smoke.ARPA> Date: 16 Dec 87 20:43:13 GMT References: <6829@brl-smoke.ARPA> <9753@mimsy.UUCP> <6830@brl-smoke.ARPA> <9770@mimsy.UUCP> <6833@brl-smoke.ARPA> <3297@ulysses.homer.nj.att.com> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 65 In article <3297@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: >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. Please do. I haven't tried to present a complete or even very accurate description of "noalias". It isn't as bad as you may have surmised from what little I have said about it, however, and the X3J11 committee's top theoreticians all seem to have bought into the notion. >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. Yes, that's right. In fact, it does work, when you check out the actual rules. There is no prohibition against using strcpy() to copy one portion of an array into another non-overlapping portion of the same array, for example. >Is > strcpy((char*)&errno,"a") >allowed? It depends on whether the body of strcpy refers to errno. strcpy() does not affect errno. However, if you assume that it is permitted to modify errno directly as well as via a noalias pointer parameter, then that situation is a violation of the noalias constraints. The compiler is not obliged to diagnose this; it is the programmer's responsibility to use functions correctly. Note that you have strange behavior completely independently of the "noalias" issue whenever there are two paths to modify the same datum; this is known as "aliasing" and in the absence of something like "noalias" the pointer parameter would be used less efficiently since every change to a global variable or via another pointer parameter would potentially have invalidated whatever the first pointer had been pointing to. With "noalias", this invalidation has been promised to not occur, and more efficient code can be used. >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. There is simply no substitute for correct and complete interface specifications; however, "noalias" can help in specifying some parameters. The issues you raise are not caused by "noalias"; they are caused by aliasing, which has always been possible in C. I have some sympathy for the viewpoint that "noalias" adds complexity and that it will be quite a job educating programmers as to what it really means and how to deal with it. I hope I haven't gotten everyone off to a bad start by being imprecise, but I too don't yet have the official wording for this topic. It will be in the second formal public review draft, which is expected to be generally available around early February. About the only viable alternative to "noalias" would simply be to prohibit the type of optimizations that it enables. But I don't think you're going to be able to get a committee that consists primarily of compiler implementors to agree to that. (I tried, more than once.)