gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/13/88)
In article <10155@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > >I wish I knew for sure what noalias meant. > So do I---it is hard to argue against something when no one will say > exactly what that something is :-) . . . . Ok, here is one TENTATIVE proposal for the aliasing wording to appear in the second public review draft proposed C standard, borrowed without permission from the people working on the words (I was supposed to be one of them, but I got sick and missed the meeting). If you find actual technical errors, please mail them to me and I'll forward them to the appropriate people, who probably don't want to have to discuss this directly with the "public" at this time. Keep in mind that there is no guarantee that this is what will actually be in the standard, but it is the first (and only, so far) proposed draft wording about this issue that I've seen. This posting is entirely unofficial, and I hope the X3J11 members working on this don't get too angry with me for prematurely spilling the beans. However, I think it may clear up some misunderstandings caused by my previous vague descriptions of what "noalias" is all about. In any case, it should establish some useful terminology for discussing the issue. '\" This is in "troff -mm" input format, using three additional macros: '\" The "Cf" macro prints its argument in constant-width font. '\" "Cb" and "Ce" delimit a constant-width display. '\" '\" Sample definitions for these macros: .de Cf \&\\f(CW\\$1\\fP .. .de Cb .DS .ft CW .. .de Ce .ft .DE .. '\" .P Each lvalue that is a unary expression with the unary .Cf * indirection operator (either explicitly or as a result of the array subscript .Cf [] operator) contains one or more .IR handles , the smallest expressions with pointer or array type associated with the entire object of which the object referred to by the lvalue is all or a part thereof, ignoring the left operand of the comma operator, the operand of the .Cf sizeof operator, all argument expressions, and all expressions with integral type. The handles for lvalues with noalias-qualified type are .IR "noalias handles" . A handle is distinguished by the spelling of its operands and by the storage duration of the objects whose values are accessed to evaluate the handle (the .IR "handle objects" ). .P For each distinct noalias handle, it is unspecified whether the handle is associated with the entire object of which a part is designated by the otherwise identical handle of an lvalue that has the non-noalias-qualified version of the type (the .IR "actual object" ) or is associated with a distinct object (a .IR "virtual object" ) with the same size and address as the actual object. The behavior of a program that depends upon a specific implementation choice is undefined. .P A virtual object, if and when created, acquires the last-stored value of the actual object. A virtual object may be created at any sequence point of a function for which there exists a sequence point at which the storage for all handle objects is guaranteed to be reserved. A virtual object has a .IR "pending value" if it has been modified through use of its noalias handle and the actual object does not have the same value. All virtual objects with pending values for a noalias handle have their values assigned to their respective actual objects between the last sequence point before which the storage is no longer guaranteed to be reserved for a handle object of the noalias handle, and the function return. .P For each distinct noalias handle, it is unspecified whether the handle is associated with the entire object of which a part is designated by the otherwise identical handle of an lvalue that has the non-noalias-qualified version of the type (the .IR "actual object" ) or is associated with a distinct object (a .IR "virtual object" ) with the same size and address as the actual object. The behavior of a program that depends upon a specific implementation choice is undefined. .P A virtual object, if and when created, acquires the last-stored value of the actual object. A virtual object may be created at any sequence point of a function for which there exists a sequence point at which the storage for all handle objects is guaranteed to be reserved. A virtual object has a .IR "pending value" if it has been modified through use of its noalias handle and the actual object does not have the same value. All virtual objects with pending values for a noalias handle have their values assigned to their respective actual objects between the last sequence point before which the storage is no longer guaranteed to be reserved for a handle object of the noalias handle, and the function return. .P The following are examples of some lvalues and their handles: .Cb int a[2], b[3][4], i; int *p, *f(); a[1]; /* \fIsame as \fP*(a + 1)\fI, handle: \fPa */ b[i][2]; /* \fIsame as \fP*(b[i] + 2)\fI, handle: \fPb */ *p; /* \fIhandle: \fPp */ *(p + i); /* \fIhandle: \fPp */ *(i = 4, p); /* \fIhandle: \fPp */ *f(); /* \fIhandle: \fPf() */ .Ce
henry@utzoo.uucp (Henry Spencer) (01/24/88)
Well, I've read it. I *think* I understand what it means. I had been
reserving judgement until I saw the wording, just to be fair. I find I
agree with Dennis's tentative opinion: noalias is a mistake.
--
Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henrymike@arizona.edu (Mike Coffin) (01/26/88)
Thanks to the person who posted the text of the "noalias" section of
the proposed standard. Although the author(s) did a good job of
describing a very complicated concept, reading it did nothing to
change my mind about this idea. It still looks to me like the sort of
feature that, ten years from now, will cause people to shake their
heads and sigh. That would be too bad, because I think that this
committee has, by and large, done an *extremely* good job.
If implementors of highly optimizing compilers want to provide noalias
as an extension to C, fine. If, in five years, this proves to be a
great idea and everyone loves it, then it should perhaps be considered
for inclusion. Right now it is both controversial and untested, and
has no business in a standard.
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike
Tucson, AZ 85721 (602)621-4252dsill@NSWC-OAS.arpa (Dave Sill) (01/29/88)
I've read the `noalias' wording and think I understand it. What troubles me is that I still don't have a good handle :-) on `noalias'. I don't fully understand how it would be used or, inadvertently, abused. Could somebody with a good grasp of `noalias' explain it in understandable terms with liberal examples? I'm tempted to say `noalias' should be scrapped simply because it's so hard to grok, but I'd like someone to make it so clear that that's not the case. I'm no Dijkstra, but I can explain `register' to just about anyone in a couple of simple sentences... ========= The opinions expressed above are mine. "A person gets from a symbol the meaning he puts into it, and what is one man's comfort and inspiration is another's jest and scorn." -- Robert Jackson
dsill@NSWC-OAS.arpa (Dave Sill) (01/29/88)
In article <1955@bsu-cs.UUCP> Rahul Dhesi <bsu-cs!dhesi> writes: >I'm assuming that the definition of noalias will ensure that making it >vanish with a #define will result in a semantically-equivalent >program. If this is not so it should be made to. If this was so, `noalias' could be replaced with a #pragma. ========= The opinions expressed above are mine. How much work would a network work if a network could net work?