Re: Ada style of passing 'in' parameters considered dangerous?

[gautier_niouzes@hotmail.com (Gautier)]

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!