Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!haven!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.lang.c Subject: Re: Whither _noalias_? Message-ID: <15142@smoke.brl.mil> Date: 9 Feb 91 09:57:07 GMT References: <1991Feb7.050917.24550@zoo.toronto.edu> <1991Feb8.211734.22306@portia.Stanford.EDU> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 20 In article <1991Feb8.211734.22306@portia.Stanford.EDU> dhinds@elaine24.stanford.edu (David Hinds) writes: >Was it really that hard >to come up with a clear and useful definition of "noalias", or was it just >a result of committee politics fouling it up? Henry's presentation of the history is a bit biased. In fact it is remarkably hard to get a specification for nonaliasing right (meaning: the programmer is able to readily control when the compiler is allowed to hyperoptimize and when aliasing may occur). X3J11 has been wrangling with an interpretation request that involves similar logical issues for over a year now, with no resolution in sight. The root problem is that C serves both low-level and high-level programming goals, and this sort of thing is where no single compromise seems to satisfy both kinds of usage of the language. >Was the proposal to just >have "noalias" apply to function parameters? It would seem to be much >more useful if it could be used on any pointer variable. It was a type qualifier.