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-23 04:35:14 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!newsfeed!fu-berlin.de!uni-berlin.de!p62.246.193.196.tisdip.tiscali.DE!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interesting effects in array renaming Date: Mon, 23 Jun 2003 13:37:54 +0200 Organization: At home Message-ID: References: <3EF5E6B8.3030203@spam.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: p62.246.193.196.tisdip.tiscali.de (62.246.193.196) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1056368109 26328874 62.246.193.196 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:39593 Date: 2003-06-23T13:37:54+02:00 List-Id: Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > : > : "... any constraint implied by the subtype_mark of the > : object_renaming_declaration is ingored)." > : > : I.e. whatever subtype you, a programmer, might specify I, the compiler, > : will shamelessly ignore it! > : > : How safe! Do you really think it is OK? Consider this: > [...] > : I see only two alternatives: > : > : Either to add a dynamic semantics ensuring that the result of renaming > : is a valid object of the declared subtype. [X2 raises Constraint_Error > : if Constrained'Range /= X'Range] > > I think the compiler could warn about possibly > "incompatible" constraints in a renaming declaration. > > Have you written to the producers of your compiler? 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. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de