Passing a String to a C/C++ Subprogram (Special Case)

Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.

Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:

     . . .
        A_String : String (1 .. 30);
        pragma Convention (C, A_String);
        . . .
        procedure C_Prog (C_String : in String);
        pragma Import (Entity => C_Prog, ...);
     begin
        C_Prog (C_String => A_String);
     . . .

and have it work properly?

This method, of course, leaves it up to the client developer to insert any necessary nul characters to terminate the string, if is is smaller than the declared bound.

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Adam Beneschan]

On Tuesday, October 15, 2013 12:54:18 PM UTC-7, Eryndlia Mavourneen wrote:
> I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.
> 
> 
> 
> Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
> 
> 
> 
>      . . .
>         A_String : String (1 .. 30);
>         pragma Convention (C, A_String);
>         . . .
>         procedure C_Prog (C_String : in String);
>         pragma Import (Entity => C_Prog, ...);
>      begin
>         C_Prog (C_String => A_String);
>      . . .
> 
> and have it work properly?

B.3(70) says, "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."  Since a String is defined as an array of Character in Ada, this should cause a "char*" argument to be passed.  However, this is in a section marked "Implementation Advice", so there's a possibility that a particular Ada compiler may not conform.  You'll want to check the Ada compiler manual and/or try it yourself and see what code it generates.  Note that this means the 'First and 'Last of the string parameter won't be passed to the C routine.  But it looks like you know that already. 

                               -- Adam

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Jeffrey Carter]

On 10/15/2013 12:54 PM, Eryndlia Mavourneen wrote:
>
> Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
>
>       . . .
>          A_String : String (1 .. 30);
>          pragma Convention (C, A_String);
>          . . .
>          procedure C_Prog (C_String : in String);
>          pragma Import (Entity => C_Prog, ...);
>       begin
>          C_Prog (C_String => A_String);
>       . . .
>
> and have it work properly?
>
> This method, of course, leaves it up to the client developer to insert any necessary nul characters to terminate the string, if is is smaller than the declared bound.

As Beneschan pointed out, this should work, assuming your compiler equates a 
Character to a C char, and C_Prog expects a string of exactly 30 characters (in 
which case a convention-C subtype for the parameter would be in order) or a 
NUL-terminated variable-length string and the caller remembers to put a NUL in 
the passed string.

Relying on any of that is asking for trouble, especially if this is, as you 
imply, part of a larger project. Eventually this will be modified by someone who 
will get it wrong. Much safer is to use the facilities of Interfaces.

If I were doing this, I would wrap each in an Ada subprogram that ensures the 
String will be passed correctly to C. Ultimately it will be less effort.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Tuesday, October 15, 2013 3:11:30 PM UTC-5, Adam Beneschan wrote:
> On Tuesday, October 15, 2013 12:54:18 PM UTC-7, Eryndlia Mavourneen wrote:
> 
> > I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.
> 
> > Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
> 
> >      . . .
> >         A_String : String (1 .. 30);
> >         pragma Convention (C, A_String);
> >         . . .
> >         procedure C_Prog (C_String : in String);
> >         pragma Import (Entity => C_Prog, ...);
> >      begin
> >         C_Prog (C_String => A_String);
> >      . . .
> 
> > and have it work properly?
> 
> 
> 
> B.3(70) says, "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."  Since a String is defined as an array of Character in Ada, this should cause a "char*" argument to be passed.  However, this is in a section marked "Implementation Advice", so there's a possibility that a particular Ada compiler may not conform.  You'll want to check the Ada compiler manual and/or try it yourself and see what code it generates.  Note that this means the 'First and 'Last of the string parameter won't be passed to the C routine.  But it looks like you know that already. 
> 
> 
> 
>                                -- Adam

Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.  lol
I guess you choose your poison.

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Tuesday, October 15, 2013 3:59:21 PM UTC-5, Jeffrey Carter wrote:
> On 10/15/2013 12:54 PM, Eryndlia Mavourneen wrote:
> 
> >  . . .
> 
> If I were doing this, I would wrap each in an Ada subprogram that ensures the 
> String will be passed correctly to C. Ultimately it will be less effort.
> 

Thanks, Jeff.  This could be a good way to manage things.  Unfortunately, I can not guarantee that I can perform a trim operation or that the last character is indeed not being used (for the placement of a nul).  I suppose I could create the wrapper, as you said, and copy the String (1 .. size) to a String (1 .. size + 1) and place a nul in the last character of the target string.  Of course, this does not add a lot of overhead for short strings, but it is a hard real-time system.

It sounds as if I need to get with my people and get a further, clear consensus about how this stuff is going to be used, in reality.

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Shark8]

On Tuesday, October 15, 2013 3:13:09 PM UTC-6, Eryndlia Mavourneen wrote:
> On Tuesday, October 15, 2013 3:59:21 PM UTC-5, Jeffrey Carter wrote:
> 
> > On 10/15/2013 12:54 PM, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > >  . . .
> 
> > 
> 
> > If I were doing this, I would wrap each in an Ada subprogram that ensures the 
> 
> > String will be passed correctly to C. Ultimately it will be less effort.
> 
> > 
> 
> 
> 
> Thanks, Jeff.  This could be a good way to manage things.  Unfortunately, I can not guarantee that I can perform a trim operation or that the last character is indeed not being used (for the placement of a nul).  I suppose I could create the wrapper, as you said, and copy the String (1 .. size) to a String (1 .. size + 1) and place a nul in the last character of the target string.  Of course, this does not add a lot of overhead for short strings, but it is a hard real-time system.
> 
> 
> 
> It sounds as if I need to get with my people and get a further, clear consensus about how this stuff is going to be used, in reality.
> 
> 
> 
> -- Eryndlia Mavourneen (KK1T)

Could you use an Ada 2012 subtype predicate? something like:

    Type Transport_String is array (1..31) of Character
        with Default_Component_Value => ASCII.NUL,
        Dynamic_Predicate => Transport_String(Transport_String'Last) = ASCII.NUL;

Actually I'm rather disappointed that there aren't static_predicates available for Arrays. I had hoped to, in my OpenGL binding, have something like the following available for the vector operations:

    Type RGBA is (Red, Blue, Green, Alpha); 
    Subtype RGB is RGBA range Red..Blue;
    
    --  Declare the general Vector-type for OprnGL which has vectors
    --  of three or four components of RGBA [A being optional], always
    --  starting with R.
    Type Float_Vector is array(RGBA range <>) of Float
        with Static_Predicate => Float_Vector'First = Red;

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Jeffrey Carter]

On 10/15/2013 02:13 PM, Eryndlia Mavourneen wrote:
>
> Thanks, Jeff.  This could be a good way to manage things.  Unfortunately, I
> can not guarantee that I can perform a trim operation or that the last
> character is indeed not being used (for the placement of a nul).  I suppose I
> could create the wrapper, as you said, and copy the String (1 .. size) to a
> String (1 .. size + 1) and place a nul in the last character of the target
> string.  Of course, this does not add a lot of overhead for short strings,
> but it is a hard real-time system.

I would use the To_C or New_String functions to ensure that what is being passed 
to C is convention-C and NUL-terminated.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Dmitry A. Kazakov]

On Tue, 15 Oct 2013 14:02:17 -0700 (PDT), Eryndlia Mavourneen wrote:

> Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.

Yes, but you still can work around that:

procedure Foo (A : String) is
   procedure C_Prog (C_String : Address);
   pragma Import (...);
   pragma Assert (Character'Size = char'Size); -- sic!
begin
   C_Prog (A (A'First)'Address);

P.S. Of course To_C is what you should better use.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Jeffrey Carter]

On 10/16/2013 12:17 AM, Dmitry A. Kazakov wrote:
>
> procedure Foo (A : String) is
>     procedure C_Prog (C_String : Address);
>     pragma Import (...);
>     pragma Assert (Character'Size = char'Size); -- sic!
> begin
>     C_Prog (A (A'First)'Address);

This will fail on a number of compilers. An Ada Address is not necessarily the 
same as a C pointer.

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Martin]

On Tuesday, October 15, 2013 10:02:17 PM UTC+1, Eryndlia Mavourneen wrote:
> On Tuesday, October 15, 2013 3:11:30 PM UTC-5, Adam Beneschan wrote:
> 
> > On Tuesday, October 15, 2013 12:54:18 PM UTC-7, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > > I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.
> 
> > 
> 
> > > Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
> 
> > 
> 
> > >      . . .
> 
> > >         A_String : String (1 .. 30);
> 
> > >         pragma Convention (C, A_String);
> 
> > >         . . .
> 
> > >         procedure C_Prog (C_String : in String);
> 
> > >         pragma Import (Entity => C_Prog, ...);
> 
> > >      begin
> 
> > >         C_Prog (C_String => A_String);
> 
> > >      . . .
> 
> > 
> 
> > > and have it work properly?
> 
> > 
> 
> > 
> 
> > 
> 
> > B.3(70) says, "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."  Since a String is defined as an array of Character in Ada, this should cause a "char*" argument to be passed.  However, this is in a section marked "Implementation Advice", so there's a possibility that a particular Ada compiler may not conform.  You'll want to check the Ada compiler manual and/or try it yourself and see what code it generates.  Note that this means the 'First and 'Last of the string parameter won't be passed to the C routine.  But it looks like you know that already. 
> 
> > 
> 
> > 
> 
> > 
> 
> >                                -- Adam
> 
> 
> 
> Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.  lol
> 
> I guess you choose your poison.
> 
> 
> 
> -- Eryndlia Mavourneen (KK1T)


Annex B is part of the 'core language' - it isn't optional. Annex A and J are also 'core'. The 'Special Needs Annex' sections are the 'optional' parts of the language. See 1.1.2 and 1.1.3.

-- Martin

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Wednesday, October 16, 2013 12:32:36 PM UTC-5, Martin wrote:
> On Tuesday, October 15, 2013 10:02:17 PM UTC+1, Eryndlia Mavourneen wrote:
> 
> > On Tuesday, October 15, 2013 3:11:30 PM UTC-5, Adam Beneschan wrote:
> 
> > 
> 
> > > On Tuesday, October 15, 2013 12:54:18 PM UTC-7, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >      . . .
> 
> > 
> 
> > > >         A_String : String (1 .. 30);
> 
> > 
> 
> > > >         pragma Convention (C, A_String);
> 
> > 
> 
> > > >         . . .
> 
> > 
> 
> > > >         procedure C_Prog (C_String : in String);
> 
> > 
> 
> > > >         pragma Import (Entity => C_Prog, ...);
> 
> > 
> 
> > > >      begin
> 
> > 
> 
> > > >         C_Prog (C_String => A_String);
> 
> > 
> 
> > > >      . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > and have it work properly?
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > B.3(70) says, "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."  Since a String is defined as an array of Character in Ada, this should cause a "char*" argument to be passed.  However, this is in a section marked "Implementation Advice", so there's a possibility that a particular Ada compiler may not conform.  You'll want to check the Ada compiler manual and/or try it yourself and see what code it generates.  Note that this means the 'First and 'Last of the string parameter won't be passed to the C routine.  But it looks like you know that already. 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > >                                -- Adam
> 
> > 
> 
> > 
> 
> > 
> 
> > Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.  lol
> 
> > 
> 
> > I guess you choose your poison.
> 
> > 
> 
> > 
> 
> > 
> 
> > -- Eryndlia Mavourneen (KK1T)
> 
> 
> 
> 
> 
> Annex B is part of the 'core language' - it isn't optional. Annex A and J are also 'core'. The 'Special Needs Annex' sections are the 'optional' parts of the language. See 1.1.2 and 1.1.3.
> 
> 
> 
> -- Martin

In the Ada95 LRM (I have to use Ada95.), in the introduction to Annex B (B 2/3) it states:  "Support for interfacing to any foreign language is optional."

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Martin]

On Wednesday, October 16, 2013 6:42:29 PM UTC+1, Eryndlia Mavourneen wrote:
> On Wednesday, October 16, 2013 12:32:36 PM UTC-5, Martin wrote:
> 
> > On Tuesday, October 15, 2013 10:02:17 PM UTC+1, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > > On Tuesday, October 15, 2013 3:11:30 PM UTC-5, Adam Beneschan wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > On Tuesday, October 15, 2013 12:54:18 PM UTC-7, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >      . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >         A_String : String (1 .. 30);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >         pragma Convention (C, A_String);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >         . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >         procedure C_Prog (C_String : in String);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >         pragma Import (Entity => C_Prog, ...);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >      begin
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >         C_Prog (C_String => A_String);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >      . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > and have it work properly?
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > B.3(70) says, "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."  Since a String is defined as an array of Character in Ada, this should cause a "char*" argument to be passed.  However, this is in a section marked "Implementation Advice", so there's a possibility that a particular Ada compiler may not conform.  You'll want to check the Ada compiler manual and/or try it yourself and see what code it generates.  Note that this means the 'First and 'Last of the string parameter won't be passed to the C routine.  But it looks like you know that already. 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > >                                -- Adam
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.  lol
> 
> > 
> 
> > > 
> 
> > 
> 
> > > I guess you choose your poison.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > -- Eryndlia Mavourneen (KK1T)
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Annex B is part of the 'core language' - it isn't optional. Annex A and J are also 'core'. The 'Special Needs Annex' sections are the 'optional' parts of the language. See 1.1.2 and 1.1.3.
> 
> > 
> 
> > 
> 
> > 
> 
> > -- Martin
> 
> 
> 
> In the Ada95 LRM (I have to use Ada95.), in the introduction to Annex B (B 2/3) it states:  "Support for interfacing to any foreign language is optional."
> 
> 
> 
> -- Eryndlia Mavourneen (KK1T)

That looks like Ada2012 RM rather than Ada95 (or Ada2005) [http://www.ada-auth.org/standards/12rm/html/RM-B.html].

But I do like the Ada2012 wording...it seems clearer - either the compiler has to indicate the lack of support; or exception has to be raised. If neither of those occur then your code should work as expected.

-- Martin

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Wednesday, October 16, 2013 12:54:45 PM UTC-5, Martin wrote:
> On Wednesday, October 16, 2013 6:42:29 PM UTC+1, Eryndlia Mavourneen wrote:
> 
> > On Wednesday, October 16, 2013 12:32:36 PM UTC-5, Martin wrote:
> 
> > 
> 
> > > On Tuesday, October 15, 2013 10:02:17 PM UTC+1, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > On Tuesday, October 15, 2013 3:11:30 PM UTC-5, Adam Beneschan wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > On Tuesday, October 15, 2013 12:54:18 PM UTC-7, Eryndlia Mavourneen wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > > I have a couple of strings that are bounded; that is, they are essentially fixed-length strings, and I need to pass them as "in" parameters to a subprogram that may or may not be written in C/C++.  I don't really want to hassle with the Interfaces packages for this, since the subprogram language is indefinite, and the strings are part of a package that many others likely will want to use, and the strings most likely will be used as standard Ada fixed-length strings.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > > Q: Is there any reason that I cannot just declare each of them in this way, assuming the subprogram is written in C/C++:
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >      . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >         A_String : String (1 .. 30);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >         pragma Convention (C, A_String);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >         . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >         procedure C_Prog (C_String : in String);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >         pragma Import (Entity => C_Prog, ...);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >      begin
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >         C_Prog (C_String => A_String);
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > >      . . .
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > > and have it work properly?
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > B.3(70) says, "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."  Since a String is defined as an array of Character in Ada, this should cause a "char*" argument to be passed.  However, this is in a section marked "Implementation Advice", so there's a possibility that a particular Ada compiler may not conform.  You'll want to check the Ada compiler manual and/or try it yourself and see what code it generates.  Note that this means the 'First and 'Last of the string parameter won't be passed to the C routine.  But it looks like you know that already. 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > >                                -- Adam
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.  lol
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > I guess you choose your poison.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > > -- Eryndlia Mavourneen (KK1T)
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Annex B is part of the 'core language' - it isn't optional. Annex A and J are also 'core'. The 'Special Needs Annex' sections are the 'optional' parts of the language. See 1.1.2 and 1.1.3.
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > -- Martin
> 
> > 
> 
> > 
> 
> > 
> 
> > In the Ada95 LRM (I have to use Ada95.), in the introduction to Annex B (B 2/3) it states:  "Support for interfacing to any foreign language is optional."
> 
> > 
> 
> > 
> 
> > 
> 
> > -- Eryndlia Mavourneen (KK1T)
> 
> 
> 
> That looks like Ada2012 RM rather than Ada95 (or Ada2005) [http://www.ada-auth.org/standards/12rm/html/RM-B.html].
> 
> 
> 
> But I do like the Ada2012 wording...it seems clearer - either the compiler has to indicate the lack of support; or exception has to be raised. If neither of those occur then your code should work as expected.
> 
> 
> 
> -- Martin

Yes.  You're right.  My Mistake.

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Adam Beneschan]

On Wednesday, October 16, 2013 10:32:36 AM UTC-7, Martin wrote:
 
> > Yes, Adam.  Thank you.  Of course, Annex B is optional anyway.  lol 
> > I guess you choose your poison.

> 
> Annex B is part of the 'core language' - it isn't optional. Annex A and J are also 'core'. The 'Special Needs Annex' sections are the 'optional' parts of the language. See 1.1.2 and 1.1.3.

True, but implementations aren't required to support any foreign language described in Annex B.  B(2): "Support for interfacing to any foreign language is optional."  So it's not required for an Ada compiler to support interfacing to C.  (And I hope it wouldn't be, not because interfacing to C isn't important, but I sure wouldn't want every compiler to be required to interface to COBOL and Fortran, which are also part of Annex B.)

                           -- Adam

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Simon Wright]

That was a 595-line post for one line of payload! Try clicking on "show
quoted text" to see what it looks like to us Emacs-users :-)

I can select Treatment > Hide citation or Commands > Hide > Citation,
but that ends up like the Google Groups view where you don't see _any_
cited text.

I see there's a set of "Gnus Outlook Deuglify" options, perhaps there
needs to be a "Google Groups Deuglify" set ... starting from
gnus-article-hide-citation, maybe ...

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Wednesday, October 16, 2013 2:40:04 PM UTC-5, Simon Wright wrote:
> That was a 595-line post for one line of payload! Try clicking on "show


Whoops!

Re: Passing a String to a C/C++ Subprogram (Special Case)

[sbelmont700]

Is it not also true that an Ada Character is not necessarily the same mapping as a C char?  If the C program has to output the glyphs and not just deal with the bytes, I would think it would be subject to things like the current code page, etc.

-sb

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Adam Beneschan]

On Wednesday, October 16, 2013 1:17:32 PM UTC-7, sbelm...@gmail.com wrote:
> Is it not also true that an Ada Character is not necessarily the same mapping as a C char?  If the C program has to output the glyphs and not just deal with the bytes, I would think it would be subject to things like the current code page, etc.

While that may be true, I don't know that it means much of anything.  The meaning of a "char" in C is whatever the person writing the code intended it to mean.  "char" types are the only 8-bit integer types in C, so a "char" can be used to represent a byte from a binary file, a character in the Latin-1 character set, a character in some other 256-character subset of Unicode, a portion of a multi-byte character in the UTF-8 representation of a character, a Boolean value, or anything else that fits in 8 bits.  So you can't take anything for granted and you pretty much have to know what you're doing, which is the case any time you're working with C anyway.  Hopefully we can presume that Eryndlia has already thought about this and knows what values the C code she's interfacing to is expecting to be in those bytes.

                            -- Adam  

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Martin]

Absolutely, but the RM seems to cover all cases 1) it works; 2) runtime exception; or 3) compiler error. So, if you get a running, non-exception raising program, it should "work" as you'd expect, no?

-- Martin

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Adam Beneschan]

On Wednesday, October 16, 2013 2:31:09 PM UTC-7, Martin wrote:
> Absolutely, but the RM seems to cover all cases 1) it works; 2) runtime exception; or 3) compiler error. So, if you get a running, non-exception raising program, it should "work" as you'd expect, no?

Martin, I can't tell what post you're responding to.

                              -- Adam

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Martin]

On Wednesday, October 16, 2013 10:41:09 PM UTC+1, Adam Beneschan wrote:
> On Wednesday, October 16, 2013 2:31:09 PM UTC-7, Martin wrote:
> 
> > Absolutely, but the RM seems to cover all cases 1) it works; 2) runtime exception; or 3) compiler error. So, if you get a running, non-exception raising program, it should "work" as you'd expect, no?
> 
> 
> 
> Martin, I can't tell what post you're responding to.
> 
> 
> 
>                               -- Adam

It was to your comment on the level of support required by Annex B for foreign languages. In practice, my guess is that packages Interfaces + Interfaces.C, Interfaces.C.* are as near universal as damn it. All others are 'at your own risk'.

-- Martin

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Georg Bauhaus]

On 15.10.13 23:13, Eryndlia Mavourneen wrote:
> Thanks, Jeff.  This could be a good way to manage things.  Unfortunately, I can not guarantee that I can perform a trim operation or that the last character is indeed not being used (for the placement of a nul).

There is, in addition, a logical bridge between the languages
in addition to the technical one:

C programmers who know the "strn..." functions of C's standard
C library will not be surprised to see a subprogram profile
involving a string that has both a char* and a size_t. (In fact,
this way of handling string data is sometimes recommended.) Then,

   type My_Size_T is mod 2**Positive'Size;

   procedure C_Prog (C_String : in String;
                     C_Size_T : in My_Size_T);

where My_Size_T reflects String's index type. It might be a slightly
more reliable approximation to what you'd write with Interfaces.*.
and Conventions applied to the types, especially in corner cases
when the string is empty, or if all components allocated are used
so that there is no room for storing a terminating '\0' in C.

There can be concerns about size_t being too different from My_Size_T
just like char'Size and Character'Size might differ. (E.g. Janus/Ada
reportedly has Positive'Size = 16 while the C compiler's size_t may
require more than 16 bits.) Sizes can be checked at compile time.

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Wednesday, October 16, 2013 3:48:11 PM UTC-5, Adam Beneschan wrote:
> . . .
> Hopefully we can presume that Eryndlia has already thought about this and knows what values the C code she's interfacing to is expecting to be in those bytes.
> 
>                             -- Adam

Yes, indeed!  The strings are either simple names or file paths.  Some important considerations are:

1) I am limited to Ada95 (so no aspects including type aspects)

2) The language of the underlying subprograms may or may not be C/C++.  This means I need to keep things as simple as possible for the client developer.  I am hoping that the "pragma Convention (C, ...)" will do what it sounds as if it does (along with a "pragma Import") to set things up properly.

3) I believe that the client developer will need to be responsible for adding any nul character, since the subprogram does not know whether there is junk at the end of the valid data.

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[sbelmont700]

If the client might not be in C anyway, I would put the onus on other units to sort it all out.  Even if a non-C client can be written to figure out a C string, who says the client language can be exported as C convention?  Better to isolate it entirely for when they inevitably change their minds.

generic
   type Client_String_Type is private;
   with function Convert_To_Client(x : String) return Client_String_Type;
   with procedure External_Prog (y : in Client_String_Type);
...

begin 
   ...
   External_Prog (Convert_To_Client("Hello World!"));
   ...


-sb

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Eryndlia Mavourneen]

On Thursday, October 17, 2013 8:58:51 AM UTC-5, sbelm...@gmail.com wrote:
> If the client might not be in C anyway, I would put the onus on other units to sort it all out.  Even if a non-C client can be written to figure out a C string, who says the client language can be exported as C convention?  Better to isolate it entirely for when they inevitably change their minds.
> 
> generic
>    type Client_String_Type is private;
>    with function Convert_To_Client(x : String) return Client_String_Type;
>    with procedure External_Prog (y : in Client_String_Type);
> ...
> begin 
>    ...
>    External_Prog (Convert_To_Client("Hello World!"));
>    ...
> 
> -sb

Interesting approach.

I am assuming that the pragmas Convention and Import will do their jobs properly, and anyway, forcing a generic on the clients is almost certain to be rejected.

-- Eryndlia Mavourneen (KK1T)

Re: Passing a String to a C/C++ Subprogram (Special Case)

[Randy Brukardt]

"Martin" <martin@thedowies.com> wrote in message 
news:50cd020a-480f-4569-990b-b2861f628bc1@googlegroups.com...
On Wednesday, October 16, 2013 6:42:29 PM UTC+1, Eryndlia Mavourneen wrote:
...
>> In the Ada95 LRM (I have to use Ada95.), in the introduction to Annex B 
>> (B 2/3) it states:  "Support for interfacing to any foreign language is 
>> optional."
>>
>That looks like Ada2012 RM rather than Ada95 (or Ada2005) 
>[http://www.ada-auth.org/standards/12rm/html/RM-B.html].
>
>But I do like the Ada2012 wording...it seems clearer - either the compiler 
>has to indicate the lack of support; or exception has to be raised. If 
>neither of those occur then your code should work as expected.

This is one of the things that falls under the so-called "Dewar rule": the 
Ada Standard never says nonsense (even when it literally does :-). No one 
ever thought that all programming languages have to be supported for 
interfacing, or that it is acceptable to accept the pragmas without actually 
implementing them. Unfortunately, the RM never actually said that. We 
figured it was better that it says so explicitly, thus we added some wording 
in Ada 2012. (My recollection is that we attempted to do so for Ada 2005, 
but put the wording in the wrong place so it didn't appear to apply where it 
should have.)

                            Randy.