Errors in postings 
Author Message
 Errors in postings

Quote:

> I quote an article of mine from April:

: Hmmm, this doesn't sound right. After all, if A and B could be aliased,
: and B and C could be aliased, then A and C could be aliased. (This is
: why the natural keyword is ``alias,'' not ``noalias.'')

Quote:
> I have always held the same position. You can see exactly the same
> position in many of my articles, and in my complaint that the Convex
> anti-aliasing mechanism makes the opposite assumption.

But, this is not correct.  Consider the example:

  extern void f(int * x, int * y, int * z);

  int a[3],b[3];
  ...
  f(a,a,b);
  f(a,b,b);
  ...

If you attempt to derive one summary for the aliasing that might
hold upon entry to "f" (i.e., without cloning specialized copies),
you discover that

  x may-alias y
  y may-alias z
  x NOT-alias z

David Chase
Sun Microsystems



Sat, 01 May 1993 09:41:39 GMT  
 Errors in postings

Quote:


> > I quote an article of mine from April:
> > : Hmmm, this doesn't sound right. After all, if A and B could be aliased,
> > : and B and C could be aliased, then A and C could be aliased. (This is
> > : why the natural keyword is ``alias,'' not ``noalias.'')
> > I have always held the same position. You can see exactly the same
> > position in many of my articles, and in my complaint that the Convex
> > anti-aliasing mechanism makes the opposite assumption.
> But, this is not correct.

What is not correct? We were talking about Jim's misquotes.

Quote:
> Consider the example:

You have a different interpretation of ``could be.'' You're saying that
in one particular program, A and B happen to be aliased some of the
time, and B and C happen to be aliased some of the time, but A and C are
not aliased.

I'm saying that in the universe under the assumptions that A and B can
be aliased and that B and C can be aliased, it's certainly true that A
and C can be aliased, though they might not be in a particular example.
In contrast, under the assumptions that A and B are never aliased and
that B and C are never aliased, it's *not* true that A and C are never
aliased, though it may happen that they are not aliased in a particular
example.

In case that paragraph was confusing: f(X,Y) = X and Y can be aliased.
g(X,Y) = X and Y cannot be aliased.

  ``Under the assumptions that f(A,B) and f(B,C), it's certainly true
  f(A,C), though A and C might not be aliased in a particular example.

  In contrast, under the assumptions that g(A,B) and g(B,C), it's not
  true g(A,C), though it may happen that A and C are not aliased in a
  particular example.''

Why isn't this symmetric? Because g(X,Y) is ``never f(X,Y)'', but
f(X,Y) is not ``never g(X,Y).'' The ``can''s and ``never''s are
important here.

Can-can algebra aside, alias (``these variables are sometimes aliased'')
feels like a more natural qualifier than noalias (``these variables are
never aliased''). Why? Because the quantifier in alias transcends a
specific use of a function or library and talks about how it's *meant*
to be used. In contrast, the quantifier in noalias talks about the world
as it might happen to be at one moment.

To go a bit further and introduce the missing elements: Think about the
qualifiers antialias (``these variables may be unaliased'') and
noantialias (``these variables *must* be aliased''). If I had to choose
between these two instead of alias-noalias, I'd choose the former. Why?
Because the ``may'' makes it feel more natural.

I don't know if I can give a logical explanation for an emotional issue,
but I hope this helps you understand my point.

---Dan



Sun, 02 May 1993 08:19:49 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. false error posting for replaceAll:with:

2. 2nd Posting: Link Error: To many segdef in file:8,800 - Please Help

3. 441 Error Posting to Topspeed.enterprise.beta

4. Error 47 - Revisited/Second Posting

5. Posting guidelines -- bi-weekly posting

6. Posting guidelines -- bi-weekly posting

7. Posting guidelines -- bi-weekly posting

8. Posting guidelines -- bi-weekly posting

9. Posting guidelines -- bi-weekly posting

10. Posting guidelines -- bi-weekly posting

11. Posting guidelines -- bi-weekly posting

12. Posting guidelines -- bi-weekly posting

 

 
Powered by phpBB® Forum Software