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

[Antti Sykari <jsykari@gamma.hut.fi>]

gautier_niouzes@hotmail.com (Gautier) writes: 
>> - 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!). 
 
I don't think this is enough.  For example, you can pass a largish
part of a record as an IN OUT parameter (I think you can: I'm not
exactly an Ada expert), and the record itself as IN parameter, and
modify your IN parameter that way.
 
Or you could call any other subprogram which has access to the record,
and modify it that way.  In fact, any subprogram call could change it,
so it's really impossible to know when to warn.  You should be able to
guarantee that an IN OUT object is unchanged (unless don't change it
directly yourself) and that an IN object is unchanged.
 
One (partial) solution would be restricted types, which guarantee that
they are the only means to change the object which they denote.  (As
with C99's restrict-qualified pointers, which are there primarily to
allow optimization and don't change the meaning of a correct program).
However, I'm not sure if you can actually trust the compiler to catch
all errors even in the presence of such types.  In C99, for example,
you can still have two restrict-qualified pointers to the same array
if you promise not to use them to access the same values.

Maybe they would be more useful in a more sophisticated type system
(such as Ada's) - or maybe not. A complicated thing.

-Antti