Re: Interesting effects in array renaming

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : It is same in both GNAT and ObjectAda, but it is absolutely legal
> : according to ARM. The problem is ARM itself. Which opens such a hole.
> : What sense have our complains about buffer overruns in C/C++, in
> : presense of this? It is also a range check optimization problem, because
> : the compiler cannot rely on subtype information. Very bad.
> 
> I don't think it is so bad, it is much more an issue of what
> renaming means, maybe?

No, it is an issue of which meaning has an explicit specifying of a subtype. 
I would not object if the syntax were:

X : renames Y;

But it isn't.

> Most prominently, you give another name
> to an entity, you don't make a new entity.

Really? To me a "view" is definitely an "entity". You probably mean that 
renaming should not create a new object. But it is no matter, imposing a 
constraint on an existing object does not change the object. It is merely a 
precondition.

> Why should the new
> name denote an entity wich has its bounds changed, despite
> being "just another name"?

The answer depends on whether bounds is a property of (1) a value or of (2) 
a type. For an unconstrained array type you have (1), for a constrained 
array [sub]type (2). So when you rename one to another you have a clash 
between (1) and (2). It has to be reconciled. In the example I gave

for I in Constrained'Range loop
   X2 (I) := 0;
end loop;

may raise Constraint_Error or else corrupt memory if range checks are 
suppressed. It is abolutely unacceptable. To put it in one sentence: either 
you change bounds or you check them.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de