From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,af3dada69080e420 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-24 00:32:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-043-178.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interesting effects in array renaming Date: Tue, 24 Jun 2003 09:35:11 +0200 Organization: At home Message-ID: References: <3EF5E6B8.3030203@spam.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-043-178.arcor-ip.net (145.254.43.178) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1056439943 27282922 145.254.43.178 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:39638 Date: 2003-06-24T09:35:11+02:00 List-Id: Georg Bauhaus wrote: > Dmitry A. Kazakov 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