Re: String parameters to exported routines - What should a compiler do?

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Tuck says

<<This is what I would recommend.  Use the bounds of the index subtype.
>>


I strongly disagree. I think this is error prone, and no, GNAT does NOT do
this, and regards the construct as illegal or generates a warning, I can't
remember which right now, I think in fact it should be illegal.

If you pass a string from a C program to an exported Ada program, e.g.
"abc", and you allow a construct with String as a formal on the Ada side,
typical programmers who do not understand the issues will expect the bounds
to be 1..3, and their programs will go berserk overwriting memory when they
use 'Range. It should never be this easy to import this kind of overwriting
into an Ada program.

If you want the effect that Tuck recommends, then get it by defining a type

   subtype Big_String is String (Natural);

and use this as the type. These kind of types (we always call them Big_xxx
by convention in the GNAT sources) are often useful in dealing with cases
where bounds are simply not available. They have the advantage of constantly
reminding the programmer that the bounds are NOT available.

Yes, I know AdaMagic supplies bounds in this case, and we considered doing
this in GNAT as well, but rejected the idea as too dangerous, per above
reasoning.

Generally it is of course desirable for Ada 95 compilers to do the same
think in the same situation, but it is not an absolute principle, and when
compilers do things that are outside the RM (you cannot deduce Tuck's 
recommendation from the RM), they should not always be copied.

Sometimes it seems reasonable to copy things. For example, even though
the AdaMagic C_Pass_By_Copy facility is a bit of a kludge (a sufficient
kludge that the ARG cannot yet bring itself to endorse this as the
proper solution to the error in the RM, see below), it seemed reasonable
to copy this into GNAT, and indeed the ARA (not quite so bound as the ARG
by considerations of elegance :-) decided that this should be the common
approach.

P.S. the RM error I refer to above is the recommendation that all structs
should be passed by reference. This was a plain mistake, since it would
forbid compilers from duplicating the typical C callings sequence in which
small structs are passed by copy in registers. 
(we are talking here specifically about passing mechanisms for convention C)

Finally, Tuck says there is no difference between export and import with
regard to the original topic.

That's quite wrong.

Importing functions is not a problem. It is fine to discard bounds on the
way to C, since C does not expect the bounds anyway. On the other hand,
exporting is a real problem. Here we have no bounds on the C side.

Tuck recommends implicitly generating bogus bounds on the way to Ada
GNAT feels that it is safer not to allow the notation, given that it
adds danger, but no expressive power.