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

[Martin <martin@thedowies.com>]

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