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-11 01:14:53 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: gautier_niouzes@hotmail.com (Gautier)
Newsgroups: comp.lang.ada
Subject: Re: Ada style of passing 'in' parameters considered dangerous?
Date: 11 Feb 2003 01:14:52 -0800
Organization: http://groups.google.com/
Message-ID: <17cd177c.0302110114.2c46b52@posting.google.com>
References: <86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi>
NNTP-Posting-Host: 213.173.163.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1044954893 29528 127.0.0.1 (11 Feb 2003 09:14:53
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 11 Feb 2003 09:14:53 GMT
Xref: archiver1.google.com comp.lang.ada:33984
Date: 2003-02-11T09:14:53+00:00
List-Id: <comp.lang.ada>

Antti:

> My concerns here are:
> 
> - Is this generally considered a dangerous thing in Ada (or in
>   general)?

Not enough!

> - 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.

See my other reply. IIRC, the worst were cases where procedure P
calls Q, Q calls R and R modifies an IN parameter because it references
also a [IN] OUT, then even the IN parameter of P is also modified after
the call to Q. Add loops and so on... :-}

> - If there are such cases, could it have been prevented by having
>   different policy in the language?  Do you think it would've been
>   better to force the programmer to specify the parameter passing
>   mechanism, for example?

Yes and no: the explicit passing mechanism has the advantage of being
...explicit, but it is not always optimal according to target system.
The "in,in/out,out" is very readable and catches a lot of errors.
The "in", especially, ensures a fast mode and avoiding an explicit
modification. The security problem happens rarely, but it happens.

I'd suggest that compilers issue a warning when the following
conditions meet:
 - there are parameters of the same type, some IN, some [IN] OUT
 - the compiler decides to pass the IN by reference
 - an IN parameter is referenced after an IN OUT was modified
and also:
 - for a call, when the same variable is passed to an IN
   by reference and an [IN] OUT (it doesn't solve the issue of
   ".all" objects!).
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!