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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6a0391eb7e0327d5
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-02-08 18:34:41 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!slip-12-64-18-150.mis.prserv.NET!not-for-mail
From: Vinzent Hoefler <JeLlyFish.software@gmx.net>
Newsgroups: comp.lang.ada
Subject: Re: Ada style of passing 'in' parameters considered dangerous?
Date: Sat, 08 Feb 2003 21:33:18 -0500
Organization: JeLlyFish software
Message-ID: <b24env$18emm2$1@ID-175126.news.dfncis.de>
References: <86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi>
 <wcc3cmyw6t5.fsf@shell01.TheWorld.com>
NNTP-Posting-Host: slip-12-64-18-150.mis.prserv.net (12.64.18.150)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Trace: fu-berlin.de 1044758080 42425026 12.64.18.150 (16 [175126])
X-Newsreader: Forte Agent 1.8/32.548
Xref: archiver1.google.com comp.lang.ada:33925
Date: 2003-02-08T21:33:18-05:00
List-Id: <comp.lang.ada>

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

>Antti Sykari <jsykari@gamma.hut.fi> writes:
>
>> - Have you encountered a non-trivial real-life case where the
>>   programmer has shot himself in the foot in the form of
>>   implementation-defined behavior because of the error mentioned =
above?
>>   I'd be interested to hear of any such cases.

I once did encounter such problem. It wasn't Ada, it was Pascal, so it
had nothing to do with "implementation defined", but if you take a
closer look to it, the problem might be considered as similar.

I changed the parameter mode of a string to "const" because there was
no write access to it. So then it was passed by reference instead of
by value like it did before. The bad thing was, this string was part
of another parameter to this procedure so indeed the string got
changed during the call. An example of badly structured data, I'd say.

>I don't know.  I would feel more comfortable if one could *prove* that
>such things can't happen.

Well, that's what SPARK is for.

>One possible solution is to disallow cases that might be aliased.

Like SPARK does. :)


Vinzent.