Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: noalias (was: Re: the "const" qualifier)
Message-ID: <11375@smoke.BRL.MIL>
Date: 21 Oct 89 23:59:37 GMT
References: <12239@cit-vax.Caltech.Edu> <11301@smoke.BRL.MIL> <3728@solo10.cs.vu.nl> <11320@smoke.BRL.MIL> <742@ccssrv.UUCP> <1989Oct19.162849.20265@utzoo.uucp> <11351@smoke.BRL.MIL> <14774@bfmny0.UU.NET>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <14774@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
>The whole noalias issue seemed intricately entangled with late 80's
>notions of addressing and optimization.  In five years it will probably
>look quite silly.

While it is true that "noalias" would basically have supported optimization
technology of the 1980s just as "register" supported compiler optimization
technology of the 1970s, I don't think either of them is "silly".  This is
a legitimate area of concern, particular in a systems programming language.

>At worst, if the concept is that vital it will be introduced in some form
>as an extension by individual vendors, and if it proves popular and
>enduring the next committee can add it from "prior art."  

Yeah, well in fact several vendors have found it necessary to add their
own, nonstandard, idiosyncratic support for this.  Since we had already
identified the requirement, is it really doing anybody a service to fail
to standardize how this is done?  I would think quite the contrary.

>It is easier for a camel to pass through the eye of a needle than for a
>standards committee to make up a useful language extension.

I suppose you have some support for this statement?