Re: Interfacing to C, output arrays

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

Simon says

  Yes, I quite understand that; the problem is that the C subprogram is
  a function and therefore can't be declared with an out parameter. I
  guess I could use the DEC pragma (valued_subprogram??), but that would
  be a tad implementation-dependent!

Sure, it would be a bit implementation dependent. At the moment it would
only work on GNAT and DEC, though I would like to see this particular
pragma (Import_Valued_Procedure) implemented more widely, since it is
very useful in interfacing.

It is indeed the sad consequence of the rule forbidding out parameters in
functions that the horrible copy in your suggested solution is the only
truly portable way of doing things.

Probably your original dubious method of passing an in parameter will work.
We assume you have used a pragma Convention (C,..) for the type of Arr (or
the whole interfacing call is dubious), and it seems reasonable to assume
that any reasonable compiler will in fact pass the array by reference in
this case, in accordance with B.3(70):

   70  An Ada parameter of an array type with component type T, of any
       mode, is passed as a t* argument to a C function, where t is the
       C type corresponding to the Ada type T.

So probably you should go back to your original scheme. If you like in GNAT
you can suppress the warning with a pragma Warnings (Off) just before the
line that gets a warning, and a pragma Warnings (On) right after.

Actually it is not only in the interfacing context that the inability to have
procedures with in out parameters can be annoying. Consider the definition
of Random in the RM, it modifies its generator argument. The only really
"correct" way to implement this function in Ada is to make the type Generator
be a controlled pointer into the heap, but this is nasty overkill, and nasty
implicit heap use, so if you look at the GNAT implementation, you will find
that it uses the same trick of "knowing" that an IN parameter is passed by
reference and hence can be modified. Of course the GNAT runtime library only
has to be portable to GNAT :-)

P.S. This is not intended to start a thread on whether it is a *good thing*
to allow in out or out parameters for functions. This point has been argued
to death more than once before, and the bottom line is that opinion is
strongly divided, but that there does not begin to be a consensus for making
this change to the language, and those who oppose it feel strongly. They
know quite well the arguments on the other side (which *I* strongly support),
but find them unconvincing. Fair enough -- that's why the change was not made,
but it does not stop it from being an annoying pain-in-the-neck!

P.P.S. In the realm of further non-portable solutions, note that GNAT's
unrestricted_access attribute could be used to avoid the copy in Simon's
truly portable solution, but then of course it would not be truly portable
any more :-)