Re: Interfacing to C non-void procedure with "out" parameters

[Alain Le Guennec <Alain.Le_Guennec@irisa.fr>]

S.J.Sangwine@Reading.ac.uk (Dr Steve Sangwine) writes:

> Can anyone shed light on the issue of interfacing between Ada95 and C
> where there is a C procedure (non-void) which returns a result *and*
> modifies some of its parameters?
> 
> The LRM, Appendix B doesn't say anything about this, and neither does
> the Ada95 Rationale as far as I can see.
> 
> I have a C procedure, for which I wanted to write an Ada95 spec, and
> import the C object code using pragma Import. Since the C procedure
> has a return result, I need an Ada function (or do I?).

If you use GNAT, you can use the pragma "Import_Valued_Procedure".
You then don't need an Ada function.
A procedure with a first OUT parameter will work.
See the GNAT Reference Manual for more information.
An excerpt follows:

`pragma Import_Valued_Procedure ...'
     Syntax:

          pragma Import_Valued_Procedure (
               [Internal                 =>] LOCAL_NAME,
            [, [External                 =>] EXTERNAL_SYMBOL]
            [, [Parameter_Types          =>] PARAMETER_TYPES]
            [, [Mechanism                =>] MECHANISM]
            [, [First_Optional_Parameter =>] IDENTIFIER]);

          EXTERNAL_SYMBOL ::=
            IDENTIFIER
          | static_string_EXPRESSION

          PARAMETER_TYPES ::=
            null
          | SUBTYPE_MARK {, SUBTYPE_MARK}

          MECHANISM ::=
            MECHANISM_NAME
          | (MECHANISM_ASSOCIATION {, MECHANISM_ASSOCIATION})

          MECHANISM_ASSOCIATION ::=
            [formal_parameter_NAME =>] MECHANISM_NAME

          MECHANISM_NAME ::=
            Value
          | Reference
          | Descriptor [([Class =>] CLASS_NAME)]

          CLASS_NAME ::= ubs | ubsb | uba | s | sb | a | nca

     This pragma is identical to `Import_Procedure' except that the
     first parameter of LOCAL_NAME, which must be present, must be of
     mode `OUT', and externally the subprogram is treated as a function
     with this parameter as the result of the function. The purpose of
     this capability is to allow the use of `OUT' and `IN OUT'
     parameters in interfacing to external functions (which are not
     permitted in Ada functions).  You may optionally use the
     `Mechanism' parameters to specify passing mechanisms for the
     parameters.  If you specify a single mechanism name, it applies to
     all parameters.  Otherwise you may specify a mechanism on a
     parameter by parameter basis using either positional or named
     notation. If the mechanism is not specified, the default mechanism
     is used.

> An Ada function must have parameters of mode 'in', implicitly or explicity,
> yet the C procedure will modify one or more of its parameters. To be
> safe, I wrote a wrapper procedure in C which had an extra parameter,
> and called this from Ada. The wrapper procedure called the real C
> procedure and returned the return result of the real C procedure in
> the extra parameter. That way the Ada spec can be a procedure and
> everything is watertight, but it is a nuisance to have this extra,
> trivial C wrapper procedure in between.
> 
> Would it work to allow the C procedure to modify a parameter that
> the Ada code thinks is read-only (i.e. 'in'), or should I play safe as
> described above. (By 'work', I mean work portably, not work when
> compiled with a specific compiler.)
> 
> Since C programmers routinely confuse the concepts of procedure and
> function (rant ....) this issue arises with almost any C code that one
> wants to interface to Ada.
> 
> Dr Steve Sangwine
> Division of Electronic Engineering
> The University of Reading, UK
> http://www.elec.rdg.ac.uk/sjs.html

Hope this helps,

-- 
	Alain Le Guennec, not speaking for IRISA.