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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,703c4f68db81387d
X-Google-Thread: 115aec,703c4f68db81387d
X-Google-Thread: f43e6,703c4f68db81387d
X-Google-Attributes: gid103376,gid115aec,gidf43e6,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!proxad.net!newsfeed.stueberl.de!feed.news.tiscali.de!news.belwue.de!newsfeed.arcor.de!news.arcor.de!not-for-mail
Date: Sun, 13 Mar 2005 03:33:52 +0100
From: Georg Bauhaus <sb463ba@user1.uni-duisburg.de>
User-Agent: Debian Thunderbird 1.0 (X11/20050116)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng
Subject: Re: Teaching new tricks to an old dog (C++ -->Ada)
References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au>
 <1110032222.447846.167060@g14g2000cwa.googlegroups.com>
 <871xau9nlh.fsf@insalien.org>
 <3SjWd.103128$Vf.3969241@news000.worldonline.dk>
 <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02>
 <d0dkq6$781$1@titan.btinternet.com>
 <1110284070.410136.205090@o13g2000cwo.googlegroups.com>
 <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com>
 <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net>
 <112s1r0rf0o8nca@corp.supernews.com> <d0l2gq$egt$1@titan.btinternet.com>
 <112sonip5v4dca6@corp.supernews.com>
 <E1vXd.352556$w62.20389@bgtnsc05-news.ops.worldnet.att.net>
 <112t3de6fu04f38@corp.supernews.com>
 <422ee0ce$0$1091$9b4e6d93@newsread2.arcor-online.net>
 <112v9p788s1684d@corp.supernews.com>
 <42307820$0$26539$9b4e6d93@newsread4.arcor-online.net>
 <1132e5g2cor3oe2@corp.supernews.com>
 <42329994$0$1093$9b4e6d93@newsread2.arcor-online.net>
 <1135t9id2cpip06@corp.supernews.com>
In-Reply-To: <1135t9id2cpip06@corp.supernews.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4233a657$0$1117$9b4e6d93@newsread2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 13 Mar 2005 03:32:56 MET
NNTP-Posting-Host: eabcaac2.newsread2.arcor-online.net
X-Trace: 
 DXC=^:FlI=bN>37c]9?QGJT=S2Q5U85hF6f;4jW\KbG]kaM8]kI_X=5Kea6?d76f1NDnT48JM^O\[iId3c`=i_SY2=m2
X-Complaints-To: abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:9280 comp.realtime:1400
 comp.software-eng:4965
Date: 2005-03-13T03:32:56+01:00
List-Id: <comp.lang.ada>

CTips wrote:

> - Enabling/disabling checking code does not change the memory layout of 
> objects.
> Ada, I believe, violates the second rule. If you disable bounds 
> checking, it will replace handles with straight pointers, which can 
> result in considerably different memory images.
> 

Hmm. Insofar as Ada object properties such as bounds are still available
to a subprogram irrespective of bounds checking ('first, 'length etc.),
this sounds too general but IANALL/compiler writer.
(I've looked at a sample case, and find the same fragments for
updating an array cell, for example.)
Data objects with representation clauses have their memory layout
specified (record layout, 'component_size etc.) so layout shouldn't
be touched by checks on/off in this case. (This is certainly true
when an object has an 'Address attribute which wouldn't make sense 
otherwise.)

If representations of access to data items at object code level
must not be changed, won't this preclude working with different
levels of optimization? Or with alternative compiler (versions)
for that matter?
I'm sure that freezing compiler flexibility is necessary when
detailed knowledge of architecture has sufficiently valuable
implications for the translated program. Still as a general rule
this sounds rather limiting, IIUC.

Georg