Ada to 'C' parameter passing problem

Ada to 'C' parameter passing problem

[Patrick]

I am using GNAT Ada on Linux.  I am trying to port from a Sun
(Solaris) implementation.  I didn't write the Ada or 'C' myself, but
am trying to make it work on Linux.  The Ada code passes five
parameters to the 'C' code.  It is trying to pass the address in each
case so that the 'C' can pass back status in the variables
(parameters).  The below Ada code (in tls.ads) contains the definition
of the function "to_c_pointer" to convert the Ada address to a
"c_pointer":
   type us1 is range 0..SYSTEM.MAX_INT;
   subtype unsigned_long is us1;
   subtype c_pointer is unsigned_long;
   -- convert ada address into a value that can be assigned
   -- to a c pointer.  The following is an example of a call to
   -- to_c_pointer: TLS.to_c_pointer(i'ADDRESS)
   function to_c_pointer is new 
      unchecked_conversion(SYSTEM.address, c_pointer);
   pragma inline(to_c_pointer);

Here is what the Ada call to 'C' looks like:
DMC_Initialize_Database_Configuration_C(
                    TLS.to_c_pointer(Configuration_Id_In'ADDRESS),
                    TLS.to_c_pointer(Configuration_Id_Len'ADDRESS),
                    TLS.to_c_pointer(Initialization_Status_Ind'ADDRESS),
                    TLS.to_c_pointer(Init_Failure_Text_In'ADDRESS),
                    TLS.to_c_pointer(Init_Failure_Text_Len'ADDRESS));

Here is what the 'C' funtion definition looks like:
DMC_Initialize_Database_Configuration_C(
                    char *Configuration_Id,
                    int *Configuration_Id_Len,
                    int *Initialization_Status,
                    char *Init_Failure_Text,
                    int *Init_Failure_Text_Len)
{

As I said, there are five parameters.  This worked fine under Solaris
(Spark compiler for Ada), but under Linux the address of the 2nd and
4th parameters ends up being zero on the 'C' side (we can tell this
with a debugger).  Using the debugger, it looks like the first
parameter on the Ada side is being passed into the first parameter on
the 'C' side.  The second parameter on the Ada side shows up on the
'C' side as the third parameter.  The third parameter on the Ada side
shows up on the 'C' side as the fifth parameter.  So, at least on the
surface, it looks as if the size of the parameter on the Ada side is
twice the size of the parameter on the 'C' and it is filling in with
zero.

Have you run into anything similar that would enable you to help me
solve this problem?

Thanks for any help you can give me,

Re: Ada to 'C' parameter passing problem

[Jeffrey Carter]

Patrick wrote:
> I am using GNAT Ada on Linux.  I am trying to port from a Sun
> (Solaris) implementation.  I didn't write the Ada or 'C' myself, but
> am trying to make it work on Linux.  The Ada code passes five
> parameters to the 'C' code.  It is trying to pass the address in each
> case so that the 'C' can pass back status in the variables
> (parameters).  The below Ada code (in tls.ads) contains the definition
> of the function "to_c_pointer" to convert the Ada address to a
> "c_pointer":
>    type us1 is range 0..SYSTEM.MAX_INT;
>    subtype unsigned_long is us1;
>    subtype c_pointer is unsigned_long;
>    -- convert ada address into a value that can be assigned
>    -- to a c pointer.  The following is an example of a call to
>    -- to_c_pointer: TLS.to_c_pointer(i'ADDRESS)
>    function to_c_pointer is new 
>       unchecked_conversion(SYSTEM.address, c_pointer);
>    pragma inline(to_c_pointer);
> 
> Here is what the Ada call to 'C' looks like:
> DMC_Initialize_Database_Configuration_C(
>                     TLS.to_c_pointer(Configuration_Id_In'ADDRESS),
>                     TLS.to_c_pointer(Configuration_Id_Len'ADDRESS),
>                     TLS.to_c_pointer(Initialization_Status_Ind'ADDRESS),
>                     TLS.to_c_pointer(Init_Failure_Text_In'ADDRESS),
>                     TLS.to_c_pointer(Init_Failure_Text_Len'ADDRESS));
> 
> Here is what the 'C' funtion definition looks like:
> DMC_Initialize_Database_Configuration_C(
>                     char *Configuration_Id,
>                     int *Configuration_Id_Len,
>                     int *Initialization_Status,
>                     char *Init_Failure_Text,
>                     int *Init_Failure_Text_Len)
> {
> 
> As I said, there are five parameters.  This worked fine under Solaris
> (Spark compiler for Ada), but under Linux the address of the 2nd and
> 4th parameters ends up being zero on the 'C' side (we can tell this
> with a debugger).  Using the debugger, it looks like the first
> parameter on the Ada side is being passed into the first parameter on
> the 'C' side.  The second parameter on the Ada side shows up on the
> 'C' side as the third parameter.  The third parameter on the Ada side
> shows up on the 'C' side as the fifth parameter.  So, at least on the
> surface, it looks as if the size of the parameter on the Ada side is
> twice the size of the parameter on the 'C' and it is filling in with
> zero.

Compare the values of System.Max_Int on the Solaris compiler and GNAT. 
GNAT supports 64-bit integers on all platforms, while it's likely the 
compiler used on Solaris only supports 32-bit integers. This might 
explain what you're seeing.

There's no need for all this complication in the interface. You could 
declare the procedure as taking System.Address for its parameters in 
Ada, and simply pass the addresses without the conversions. This would 
be a simple modification to get things working. A C pointer is generally 
an address, and Ada and C compilers for the same platform generally use 
the same representation for an address. If you want to put more effort 
into it, you could check out Annex B and learn how things are passed to 
a C subprogram, and get some type checking into the call as well.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles

Re: Ada to 'C' parameter passing problem

[Rod Chapman]

Pat.Donahue@msfc.nasa.gov (Patrick) wrote in message news:<ea3b54bb.0302180739.3cb6c159@posting.google.com>...
> I am using GNAT Ada on Linux.  I am trying to port from a Sun
> (Solaris) implementation.  I didn't write the Ada or 'C' myself, but
> am trying to make it work on Linux.
<snip>

This code looks mildly horrible.  All that messing about with
'Address and Unchecked_Conversion is in very poor style.

My advice:

1) Work out what the true Ada mode of each parameter should be.
Just because C forces pass-pointer-by-copy mechanism doesn't mean
that you should try to emulate that directly in Ada.  Is each
pointed-to parameter intended to be read, updated or both?  That
tells you that each parameter should be "in" , "out", or "in out"
in Ada terms.

2) What type is each by-reference parameter actually pointing at?
(Integer or "zero-terminated bounded array of character" are
probable answers) - that tells you the Ada types that
you should be passing.

3) Check out Annex B.3 - The package Interfaces.C gives you
lots of stuff (e.g. for turning an Ada String into a null-terminated
C string) that's useful.  Also read up the small print on
what Pragma Import does when you use Convention "C" - that
defines how Ada parameters are passed to C - very useful.

4) A C function that has multiple side-effects via
by-reference parameters shouldn't
be a function in Ada at all - it's a procedure!

That should allow you to write a clean Ada binding.

 - Rod Chapman, SPARK Team, Praxis Critical Systems

Re: Ada to 'C' parameter passing problem

[Matthew Heaney]

rod.chapman@praxis-cs.co.uk (Rod Chapman) wrote in message news:<cf2c6063.0302181150.55991a7e@posting.google.com>...
> Pat.Donahue@msfc.nasa.gov (Patrick) wrote in message news:<ea3b54bb.0302180739.3cb6c159@posting.google.com>...
> > I am using GNAT Ada on Linux.  I am trying to port from a Sun
> > (Solaris) implementation.  I didn't write the Ada or 'C' myself, but
> > am trying to make it work on Linux.
> <snip>
> 
> This code looks mildly horrible.  All that messing about with
> 'Address and Unchecked_Conversion is in very poor style.
> 
> My advice:
> 
> 4) A C function that has multiple side-effects via
> by-reference parameters shouldn't
> be a function in Ada at all - it's a procedure!

No, Rod, it's a subprogram that returns a value.  There is no
difference between a function and a procedure, except for syntax.

That Ada doesn't allow you to specify inout mode for function
parameters is a deficiency of Ada, especially since it advertises
itself as a language that is supposed to facilitate inter-language
programming.

Re: Ada to 'C' parameter passing problem

[Rod Chapman]

mheaney@on2.com (Matthew Heaney) wrote in message news:> That Ada doesn't allow you to specify inout mode for function
> parameters is a deficiency of Ada...

Wow!  This reflects somewhat of a gulf between our respective
views of language design!  (Don't get me wrong, neither position
is necessarily right or wrong, just different...)

At the SPARK end of the spectrum functions calls are expressions
which return a value and never have a side-effect.  Procedure
calls are statements which have side-effects - A rather
significant _semantic_ difference!

If you do prefer the ability to allow a function to modify its
parameters, then it should at least be good enough to confess
this to the outside-world as part of its specifiction.  The current
discussion for Ada0Y in AI231 (extending anonymous access
parameters) is welcome here, especially from a static-analysis
point of view.

 - Rod

Re: Ada to 'C' parameter passing problem

[Dmitry A. Kazakov]

On 20 Feb 2003 01:18:34 -0800, rod.chapman@praxis-cs.co.uk (Rod
Chapman) wrote:

>mheaney@on2.com (Matthew Heaney) wrote in message news:> That Ada doesn't allow you to specify inout mode for function
>> parameters is a deficiency of Ada...
>
>Wow!  This reflects somewhat of a gulf between our respective
>views of language design!  (Don't get me wrong, neither position
>is necessarily right or wrong, just different...)
>
>At the SPARK end of the spectrum functions calls are expressions
>which return a value and never have a side-effect.  Procedure
>calls are statements which have side-effects - A rather
>significant _semantic_ difference!
>
>If you do prefer the ability to allow a function to modify its
>parameters, then it should at least be good enough to confess
>this to the outside-world as part of its specifiction.  The current
>discussion for Ada0Y in AI231 (extending anonymous access
>parameters) is welcome here, especially from a static-analysis
>point of view.

[ Long awaited thread "inout parameters for functions" is again here
(:-)) ]

"To return a value via the result parameter" /= "To have no side
effects other than on the out and inout parameters"

To mix the above two is definitely a deficiency. To involve pointers
as a work-around for consequences of that deficiency is worse than
just a deficiency.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada to 'C' parameter passing problem

[Simon Wright]

rod.chapman@praxis-cs.co.uk (Rod Chapman) writes:

> mheaney@on2.com (Matthew Heaney) wrote in message news:> That Ada doesn't allow you to specify inout mode for function
> > parameters is a deficiency of Ada...
> 
> Wow!  This reflects somewhat of a gulf between our respective
> views of language design!  (Don't get me wrong, neither position
> is necessarily right or wrong, just different...)
> 
> At the SPARK end of the spectrum functions calls are expressions
> which return a value and never have a side-effect.  Procedure
> calls are statements which have side-effects - A rather
> significant _semantic_ difference!

I recall Robert Dewar saying that he thought that restricting
functions to "in" (or access) parameters was a Bad Idea -- Ada is a
programming language, not a mathematical abstraction, and there is
nothing in Ada to stop a function modifying global state. (Praise be,
say I). But Robert got outvoted during the Ada 9X process.

There would be nothing to stop SPARK requiring functions to have only
"in" parameters -- after all you disallow access parameters &
modifying global state!

Re: Ada to 'C' parameter passing problem

[Stuart Palin]

Simon Wright wrote:

> I recall Robert Dewar saying that he thought that restricting
> functions to "in" (or access) parameters was a Bad Idea -- Ada is a
> programming language, not a mathematical abstraction, and there is
> nothing in Ada to stop a function modifying global state. (Praise be,
> say I). But Robert got outvoted during the Ada 9X process.

I would think that there are [at least] a couple of
conflicting inputs to this.

1) By allowing functions to have side-effects you create
problems related to expression evaluation order - which
introduces an additional source of compiler dependencies.

2) Modifying global state is not prevented by the language
rules.  But this would be so difficult to do within the
constraints (or freedoms) of other language objectives
(principally the separate compilation of specification and
body and the hiding of internal behaviour.  Note that SPARK
addresses the issue of purity by ensuring the effect on
global state is made visible at the specification level).

Point 1 suggests it is a bad idea, point 2 shows the
language can not be entirely pure on this matter.

Would allowing function parameters to be in out/out be
encouraging a risky practice, or a recognition that the
language can not fully police the concept.

I favour the existing language rules which at least do not
'encourage' the risks that might arise through functions
with side-effects.

[RD does not usually make unconsidered statements, so I
would be interested in reading his line of arguments.  Is it
available somewhere convenient?]

--
Stuart Palin

RE: Ada to 'C' parameter passing problem

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Stuart Palin [mailto:null@0.0]
...
| [RD does not usually make unconsidered statements, so I
| would be interested in reading his line of arguments.  Is it
| available somewhere convenient?]

Search for example the 4 Nov 2001 05:07:42 answer to Nick Roberts in the
"Re: Rosen Trick [List container strawman]" thread.

It begins with "Here are the facts:", it's a kind of signature, isn't it?
:-)

Lionel Draghi
 

Re: Ada to 'C' parameter passing problem

[Jeffrey Carter]

Stuart Palin wrote:
> Simon Wright wrote:
> 
>>I recall Robert Dewar saying that he thought that restricting
>>functions to "in" (or access) parameters was a Bad Idea -- Ada is a
>>programming language, not a mathematical abstraction, and there is
>>nothing in Ada to stop a function modifying global state. (Praise be,
>>say I). But Robert got outvoted during the Ada 9X process.
> 
> [RD does not usually make unconsidered statements, so I
> would be interested in reading his line of arguments.  Is it
> available somewhere convenient?]

I'm sure it is; have you tried a search on Google groups? I think I can 
restate RD's basic argument: Functions already allow side effects, just 
not explicit side effects on their parameters. Disallowing them is an 
unnecessary impediment to developers and makes interfacing to other 
languages more difficult than is necessary; allowing them would make 
some side effects more visible.

-- 
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove

Re: Ada to 'C' parameter passing problem

[Warren W. Gay VE3WWG]

Stuart Palin wrote:
> Simon Wright wrote:
>>I recall Robert Dewar saying that he thought that restricting
>>functions to "in" (or access) parameters was a Bad Idea -- Ada is a
>>programming language, not a mathematical abstraction, and there is
>>nothing in Ada to stop a function modifying global state. (Praise be,
>>say I). But Robert got outvoted during the Ada 9X process.
> 
> I would think that there are [at least] a couple of
> conflicting inputs to this.
> 
> 1) By allowing functions to have side-effects you create
> problems related to expression evaluation order - which
> introduces an additional source of compiler dependencies.
> 
> 2) Modifying global state is not prevented by the language
> rules.  
...
> Would allowing function parameters to be in out/out be
> encouraging a risky practice, or a recognition that the
> language can not fully police the concept.
> 
> I favour the existing language rules which at least do not
> 'encourage' the risks that might arise through functions
> with side-effects.
> 
> [RD does not usually make unconsidered statements, so I
> would be interested in reading his line of arguments.  Is it
> available somewhere convenient?]
> --
> Stuart Palin

I can see that there is value in being able to say, while
reading somebody's code: "this is a function, hence there is
no state change here."

But, we all know that this isn't enforced in the language,
beyond the trivial aspect of restricting parameter use (even
that is inconsistent, because access parameters are permitted).

The function being called can be changing state within the
package it is defined in, or even calling other functions
and procedures that change states in other places to boot.
So this idea cannot be trusted to begin with.

So with my own personal "practical hat" on, I'd have to
side with those in favour of opening up the function
arguments to permit in/out, out parameters. The present
arrangement only _discourages_ side effects, and perhaps
this is something that some feel is worth maintaining.

If it becomes a requirement to provide purely functional
calls (ie. with no side effect), then I think it is
mandatory for some other mechanism to exist and
have it enforced by the compiler, IMHO.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada to 'C' parameter passing problem

[Randy Brukardt]

Stuart Palin wrote in message <3E55F70B.A254EAF@0.0>...
>[RD does not usually make unconsidered statements, so I
>would be interested in reading his line of arguments.  Is it
>available somewhere convenient?]


I believe that all of those arguments were at least partially rehashed
on Ada-Comment last fall. You can find that discussion in the !appendix
section of AI-323
   http://www.ada-auth.org/ais.html

           Randy.

Re: Ada to 'C' parameter passing problem

[Matthew Heaney]

rod.chapman@praxis-cs.co.uk (Rod Chapman) wrote in message news:<cf2c6063.0302200118.63a7ea1d@posting.google.com>...
> 
> Wow!  This reflects somewhat of a gulf between our respective
> views of language design!  (Don't get me wrong, neither position
> is necessarily right or wrong, just different...)
 
> At the SPARK end of the spectrum functions calls are expressions
> which return a value and never have a side-effect.  Procedure
> calls are statements which have side-effects - A rather
> significant _semantic_ difference!

Our disagreement is probably on how this is should be stated in the
language.

My model is that you only have subprograms, and different kinds of
subprograms simply have a different syntax for returning values back
to the caller.

For example, if I say:

O : T;

declare
   Value : constant Value_Type := Get_Value (O);
begin

then that is exactly equivalent to this:

declare
   Value : Value_Type;
begin
   Get_Value (O, Value);

Both of these sequences of statements have exactly the same effect,
which is to return an object of type Value_Type, without modifying
object O.  The keyword used indicate to the compiler that Get_Value is
a subprogram is not relevant, and I don't really care what its
spelling is.

I could change the example around.  I can set the value like this:

Value : Value_Type := ...;

declare
   Status : Status_Type;
begin
   Set_Value (O, Value, Status);

Here, we wish change the state of object O, and Set_Value returns some
information back to the caller to indicate whether the state change
was successful.

We can also rewrite the example like this:

declare
   Status : constant Status_Type := Set_Value (O, Value);
begin

This has exactly the same effect as in the previous example.  The
*only* difference in this pair of examples is the syntax of subprogram
invokation.

Ada95 lets me do both.  Apparently SPARK does not.  To me this
inconsistency seems odd.


> If you do prefer the ability to allow a function to modify its
> parameters, then it should at least be good enough to confess
> this to the outside-world as part of its specifiction.  The current
> discussion for Ada0Y in AI231 (extending anonymous access
> parameters) is welcome here, especially from a static-analysis
> point of view.

Yes, of course a function should be able to state that it modifies its
parameters, especially if it modifies them!

Realize, however, that there is a difference between the "logical"
view of an abstraction and the "physical" view.  For example, the
model for the random number is that it is a stream of values, and
invoking function Random simply returns the next value in the stream. 
In this case, it makes more sense that the function accept the
generator as an in-only (not inout) parameter.

The real issue is telling the compiler that the subprogram modifies
its arguments, in a manner independent of subprogram parameter mode
(again, because there are distinct views of the type).  Ideally, you'd
like to state this at the time of declaration of the type (instead of
letting the compiler infer this when it sees the body of the package,
which is necessarily later).

C++ solved this problem by introducing a "mutable" keyword to inform
the compiler that this variable is subject to modification,
irrespective of whether the member function is declared as const:

class C
{
   mutable int i;
public:
   void f() const;
};

and where

void C::f() const
{
   ++i;
}

Ada doesn't always do a great job of separating the logical properties
of the type from its physical properties, and it tends to conflate the
two, e.g.

package P is
   type T is range 0 .. 255; 
   function "+" (L, R : T) return T;  --clamped add
end P;

How should one implement "+" without getting infinite recursion?

It seems to me that it would be better to have an explicit way of
indicating to the compiler that a subprogram parameter is modified. 
(The spelling of the keyword that indicates to the compiler that this
is a subprogram is not relevant).

Now the compiler must sort of guess, by looking at the declaration,
e.g.

   type T is limited record
      Handle : Handle_Type (T'Access); --Rosen Trick
      ...
   end record;

Does that make it obvious to the compiler?  I don't really know.

Now of course I realize that some programmers do make a distinction
between subprograms that are spelled "function" vs. spelled
"procedure".  I do not make such a distinction.  If you decide that
subprograms spelled "function" should not modify their arguments, then
you are free to write your programs that way, and I won't try to stop
you.

However, where I must object is when those programmers try to tell
*me* that that's how I should write *my* programs.  What the original
Ada83 language designer did was to overstep his authority, and
legislate what I should do.  But the locution I choose to invoke a
subprogram that modifies its arguments should be none of his business.

The purpose of a programming language is to make it easy for a
programmer to write programs.  The language designer should not decide
by fiat how that should be done.  Both the language and its designer
should stay out of the programmer's way, and assume that it is the
programmer himself who is in the best position to decide whether a
value-returning subprogram is appropriate for the problem at hand.

So I don't agree with your characterization of this as a "language
design" issue.  If you want to try to convince me (via forums like
CLA, etc) that a function shouldn't modify its arguments, then you're
free to do that.  (And I would be interested in your arugments, even
if I don't happen to agree with them.)  But what you should NOT do is
to force me to do it your way by designing the language such that
subprogram parameter modification is prohibited by the rules of the
language.  You the language designer would be overstepping the limits
of your authority, with the concomitant effect that programmers will
either circumvent the rules, or simply chose another language.

A programming language is the programmer's servent, not his master.

Re: Ada to 'C' parameter passing problem

[Rod Chapman]

mheaney@on2.com (Matthew Heaney) wrote in message news:
> The purpose of a programming language is to make it easy for a
> programmer to write programs.  The language designer should not decide
> by fiat how that should be done.  Both the language and its designer
> should stay out of the programmer's way, and assume that it is the
> programmer himself who is in the best position to decide whether a
> value-returning subprogram is appropriate for the problem at hand.

Aha! I just can't resist steaming back in here...

For high-integrity applications, "ease of writing programs" is
hardly ever the most important thing.  We're really interested in the
ease, efficiency and cost of _verification_ of such programs.  With
that in mind as our primary design goal, then (as a language
designer), we sometimes _do_ remove or constrain language features -
the
lack of function side-effects in SPARK is one such example.

In this case we think it's worth it - the entire data-flow,
information-flow,
and VC-Generation facilities of SPARK depend on this particular
property of the language (and many others...).

We are acutely aware of the trade-off between expressive power and
analysability/verifiability of the language, so we don't take
these decisions lightly.  Matt might find SPARK
too restrictive for his interests and application domain, which is
just fine.  Many of our users think SPARK is about right.  A few of
them think it's too big!  Vive la difference!

All the best,
 Rod