Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: #defines with parameters [was :Re: v05i053: A "safe" ... ] Message-ID: <9016@smoke.BRL.MIL> Date: 30 Nov 88 18:52:33 GMT References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <122@halcdc.UUCP> <1988Nov22.170953.24489@utzoo.uucp> <264@aber-cs.UUCP> <1988Nov27.010155.29222@utzoo.uucp> <283@aber-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Distribution: eunet,world Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 59 In article <283@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >(and no, I will not even mention my HATE for volatile, far, near and >the repeated attempts to get noalias in the language, which things in >my skewed mind overshadow whatever contribution dpANS has made to >clarify so many other issues). You really ought to investigate your sources of information! The dpANS has never, to my knowledge, proposed that "far" and "near" keywords be added to C. In fact they are prohibited in a standard-conforming implementation. There have not been "repeated attempts to get noalias in the language". Since you seem to have missed the excitement, here is a brief summary of what happened concerning "noalias": There were two opposing camps concerning what the meaning of the "const" type qualifier should be. One of them, which prevailed when "const" was added to the dpANS, wanted it to be compatible with C++ "const", namely to act as a "readonly" indicator. The other camp wanted it to promise something about how a so-designated variable could validly be accessed, so that optimizers could take advantage of a "const" qualifier to provide improved optimation. In evening working sessions preceding preparation of the second formal public review dpANS, the opposing camps explored these issues and found that the aliasing aspect really could and should be separated from the readonly aspect. Thus, leaving "const" meaning essentially "readonly" and introducing a new, orthogonal "noalias" qualifier would permit programmers to accurately specify either meaning, which was considered a good solution for this issue. Therefore the new "noalias" qualifier (meaning essentially, "this object is guaranteed not to be accessed via multiple handles") was added for the second formal public review dpANS. Unfortunately, the whole area of type qualifiers had not been worded quite right in the second formal review draft. Dennis Ritchie in particular complained about the consequent pervasive effect that "noalias" would have on library functions, etc. This probably could have been fixed up to specify what was really intended in the first place, but such a big stink was made about addition of a new keyword at such a late date that it was not politically possible to salvage it. As a result, the committee withdrew "noalias" between the second and third formal public review drafts. We also have cleaned up the type qualifier specification so that it should now reflect the committee intention much better than it did in the second round. The one sad thing is that there is now no way to make the kind of promise that the optimizers needed for non-aliased objects. This reflects existing C practice, but it is unfortunate that an improvement in this area wasn't achieved. So, "noalias" was in the dpANS for ONE draft, it was an attempt to solve a real performance problem, it would have been transparent to existing code, and it was promptly removed when the reviewers responded negatively to it. That is hardly an evil plot on the part of X3J11. "volatile" also serves a need. In fact, it directly addresses one of the comments I saw earlier today in this newsgroup, about use of C for accessing device registers. Again, it is transparent to virtually all existing code, it addresses a real need, and it can be ignored by anyone who does not specifically need it. What is your objection to it?