(j3.2006) Comment 2 from TS Ballot

[Malcolm Cohen]

>Might be.  I think, though, that we are being led off base with the
>"base_addr" part of the sentence.  The intention is that someone in the
>C function who thinks he is referencing part of the actual argument
>needs to actually do that, and not wander off into other parts of
>memory.  The pointer computation would typically involve more than just
>one member of the C descriptor.   While it is basically impossible to
>write an air-tight restriction - it is always possible to play pointer
>arithmetic games that are not covered, it might be better to have
>
>"..., a pointer that is computed from information in that C descriptor..."

Sorry, but this is both vague and incorrect!

The information in that C descriptor includes lots of stuff that is perfectly ok 
to use when computing pointers inside other objects, like the element size and 
the extents.  Indeed, this is likely to happen for procedures that make copies 
of array arguments for example.

>>
>> "offset" is also not a defined term... any more than my use of "derived" was.
>>
>
>I liked "offset" because C actually has an offsetof( ) operator, whereas
>"derived" is used in C in discussions of types.

Yes but this is not about the offsetof operator, so I see no advantage.  I don't 
object to "offset" except that it didn't do the job whereas "derived" did!

>  But it is not really
>that important what steps are used to arrive at the pointer value, but
>rather that the resulting pointer points to a valid memory location.

Well the steps are important too, but the C rules handle those adequately.

The point is, a pointer value computed according to the C rules can have a lot 
of things going into it, including multiple pointers, but it can only be 
"derived from" or "based on" a single pointer (any extra ones must be subtracted 
out again along the way).

>> And it makes the following either allowed or at least up for discussion...
>>
>>    p = x->base_addr + 100;
>>    /* cannot write to p if it is not part of the described object */
>>    p = p + 10;
>>    *p = 3; /* this is ok because we did not get this by adding an offset to 
>> the
>> base_addr of the descriptor */
>>
>
>Just the sort of antics that are really hard to disallow.

Not really, this is disallowed by your latest wording (unfortunately along with 
a lot of things that should be allowed), and also disallowed by my "derived 
from" wording.

I understand that you would prefer more specific wording, but getting more 
specific makes it makes it much more likely to be wrong.  Let not the perfect be 
the enemy of the good: vague but correct is better than precise and wrogn.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.