C Strings in Ada?

C Strings in Ada?

[Andy DeFaria]

I would like to create a small package that interfaces to some C code via a
pragma INTERFACE and I have a question to all you Ada pros out there.  What
is the best way to represent C_Strings in Ada?  C's notion of a string is a
pointer to a  char of undetermined length, terminated  by a null character.
Ada has a  totally  different notion of  what  a string is.   I  can  see 3
instances where I need to use a "C_String":

	1) As parameters to a subprogram call.
	2) As a value returned from a function call.
	3) As a part of a record passed to (or returned by) a function.

I am concerned  with usability  and  efficiency as I  intend to reuse  this
package.  I  could  declare an  Ada  string  and pass the 'ADDRESS   to the
interfaced C  code  but then  I  need to append the   null character before
calling  the routine in  the package.  I could have  the package append the
null character but this would require one or two heap allocations  on every
call  and  return which I  consider a big drawback  from  the  viewpoint of
efficiency.  I have tried defining this "C_String" as it is described to C,
as an access to CHARACTER but  with this representation  I can  not look at
the  value of the Ada string  in the debugger  because the debugger faithly
shows me only the first character.  I consider this a big drawback from the
viewpoint of usability.  And how should  strings be  described as part of a
record structure?

I can see three possiblities, none of which are ideal:

(1) Represent C strings as access types to STANDARD.CHARACTER

The pointer points to a  null terminated string.  Since this  uses the same
representation as C no conversions  are  necessary.   I would  then have to
provide subprograms to convert regular Ada strings into this data type.

Advantages: 	Speed, Efficiency
Disadvantages:	Only the first character is visible in the debugger,  
		Need to call the conversion routines before making the call
		the  package.   No conversion  is  needed if  the parameter
		itself was obtained   from a  previous call  to  one  of my
		routines in the package or if the  same value was used as a
		paramater from a previous call.

(2) Represent the strings as Ada strings

In this scheme, the caller would  use only Ada  strings and my package will
always perform the conversion of the string into  a null terminated string.
  

Advantages:	Ada-like, only one interpretation of a "string" needs to be
		considered     by    the    users      of     the  package.
Disadvantanges:	The  heap manager has   to be called  not  only to allocate
		strings, but  also  records that  contain  strings.   Since
		there  are now C  versions of records  and Ada versions  of
		records, a subprogram should  be provided  to convert the C
		version of  the record to  the Ada version  of  the record.
		Also messier to implement and  users of my package may come
		upon the C version of the record by chasing pointers within
		a record.

(3) Represent the C strings as Ada strings, but ...

In this scheme,  the caller of my package  should use Ada strings that  are
terminated with the null character thereby placing  some  responisbility on
them.  My package can  then pass these  strings directly to  the C routines
I'm interfacing to.  If I discover that the caller was lazy and shucked his
responsibility by not terminating the string  with a null character, then I
can do  it for them  and thereby incur the   overhead of calling  the  heap
manager only  if  the caller  forgot to terminate  the  string with a null.
When my package returns character  strings, then  I  would have to allocate
space for these strings by calling the heap  manager but I  would be giving
the caller a string that they can in turn pass back  to  my package without
additional heap manager overhead.

Advantages:	Compromise  between the  two other method  presented.  Heap
		manager overhead  is  incurred only   when  necessary.   If
		strings that are contained in record structures are defined
		as access to Ada strings then the records  are of identical
		size.

Disadvantages:	Does   not solve  the problem of  strings  contained within
		records.  Since there is a C  version  of the record and an
		Ada version,   I  still have   the   problems of  providing
		conversion routines.

4) Combine methods 1 & 2.

This  scheme  would   basically combine    methods 1 &  2 by    using Ada's
overloaded function  call  capability.   Thus the  caller  could use either
method. 

Advantages:	Caller could  use the  Ada-like calls while  debugging  and
		migrate to the faster C-like calls.

Disadvantages:	Much more   work involved for   me in writing  the package.
		Still have a problem with strings inside of  records.  Once
		the user migrates to the faster  C-like calls it is hard to
		debug because they can't look at any "C_Strings".  Requires
		that  they change  their   code to  use  "Ada Strings"  and
		recompile.

What do you think?  How would you implement "C_Strings" in Ada?

Re: C Strings in Ada?

[stt]

Re: C_Strings in Ada

The simplest way to turn an Ada string into a string acceptable to C is:
  STR & ASCII.NUL
This works quite well in several compilers, and only
requires that the called C code ignore the additional
array descriptor often passed along with an unconstrained array.

On the other hand, if you want a type which you can manipulate
in Ada which represents a null-terminated string of unknown length,
it is best to define an access type to a *constrained* string subtype.
You can then pretty safely use unchecked conversion
to convert the address of the C string into a value of this access type.
You may then refer to the characters of the C string so long
as the C string does not exceed the length of the constrained
string subtype.  For instance:

    type C_String_Ptr is access String(1..Integer'LAST);
    function To_C_String_Ptr is new Unchecked_Conversion(
      System.Address, C_String_Ptr
    );
    Addr : System.Address;
    Ptr : C_String_Ptr;
begin
    Addr := <address of C-string>
    Ptr := To_C_String_Ptr(Addr);
    for I in Ptr'RANGE loop
        exit when Ptr(I) = ASCII.NUL;
        <do something with Ptr(I)>
    end loop;
 
If you use unchecked conversion between an address and
an access to an unconstrained array type, on many
compilers all hell breaks loose, because the access value
is assumed to be pointing at a descriptor, but you
have set it to point directly at data.

BTW, None of this works on a RATIONAL, at least not until
they get their C++ compiler working :-*.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: C Strings in Ada?

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / emery@D74SUN.MITRE.ORG (David Emery) / 10:21 am  Jun  6, 1990 /
>>What is the best way to represent C_Strings in Ada?  
>
>The right solution is to keep all strings in the Ada program as Ada
>strings, and change them to/from C strings at the point of interface
>to C.  (i.e.  within the body of Ada_routine_calling_c).  This
>preserves the Ada abstractions, and makes all the Ada things work just
>fine (e.g. 'IMAGE, which returns an Ada string).  The only other
>alternative (that makes sense to me) is to make C_STRING a private
>type derived from System.address, but you won't be able to do anything
>useful in the debugger with this.
>
>How you do this conversion is very machine dependent, but here's my
>tricks that work on Verdix (Sun 3) and Meridian (IBM PC):
>
>	procedure to_c (str : string) 
>	is
>	  procedure c_routine (addr : system.address);
>          pragma interface (C, c_routine);	-- (void) c_routine(s)
>						-- char * s;
>	  c_string : constant string := str & Ascii.NUL;
>	begin
>	  c_routine(c_string(c_string'first)'address);
>	end to_c;
>
>	function from_c  
>	    return string
>	is
>	    function c_function			
>		return System.address;		
>	    pragma interface (C, c_function);	-- char * c_function
>	    function strlen (addr : System.address)
>		return integer;
>	    pragma interface (C, strlen);	-- the C function of
>						-- the same name
>	    addr_from_c : System.address;
>	 begin
>	    addr_from_c := c_function;
>	    declare
>	      answer : string(1..strlen(addr_from_c);
>	      for answer'address use at addr_from_c;
>	    begin
>	      return answer;
>	    end;
>  	 end from_c;
>
>Hopefully what's going here is obvious, if not let me know and I'll
>send more information.
>
>				dave emery
>				emery@aries.mitre.org
>----------

I kinda agree with you that the "right" way to do this would be to keep Ada
strings as  Ada strings and do the  conversion  in package but you have not
addressed one of my critical concerns: What about  the overhead incurred by
having  to call the  heap manager to allocate a  new string just  to append
ASCII.NUL so  that the C routine I'm   calling  will be  able to handle  it
properly.   I anticipate  that this overhead will have  an severe impact on
performance and Ada already has a bad rap for being a dog.  I don't want to
add to that reputation.

Another, problem that you haven't addressed  is that  of the representation
of a string in a record.  Should it be  and  Ada access to string or should
it be the string itself.  Or should it be a C string (char *)?

Re: C Strings in Ada?

[Alex Blakemore]

In article <920025@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes:
>What is the best way to represent C_Strings in Ada?  

Dave Emery presented the following solution for some compilers.

$$	procedure to_c (str : string) 
$$	is
$$	  procedure c_routine (addr : system.address);
$$          pragma interface (C, c_routine);	-- (void) c_routine(s)
$$						-- char * s;
$$	  c_string : constant string := str & Ascii.NUL;
$$	begin
$$	  c_routine(c_string(c_string'first)'address);
$$	end to_c;
$$
$$	function from_c  
$$	    return string
$$	is
$$	    function c_function			
$$		return System.address;		
$$	    pragma interface (C, c_function);	-- char * c_function
$$	    function strlen (addr : System.address)
$$		return integer;
$$	    pragma interface (C, strlen);	-- the C function of
$$						-- the same name
$$	    addr_from_c : System.address;
$$	 begin
$$	    addr_from_c := c_function;
$$	    declare
$$	      answer : string(1..strlen(addr_from_c);
$$	      for answer'address use at addr_from_c;
$$	    begin
$$	      return answer;
$$	    end;
$$  	 end from_c;

Mr. DeFaria replied
> I kinda agree with you that the "right" way to do this would be to keep Ada
> strings as  Ada strings and do the  conversion  in package but you have not
> addressed one of my critical concerns: What about  the overhead incurred by
> having  to call the  heap manager to allocate a  new string just  to append
> ASCII.NUL so  that the C routine I'm   calling  will be  able to handle  it

I dont think this solution *requires* heap allocation.  A good compiler would 
be free to use stack space for the C strings in these cases, both for
the local constant c_string and for the return value.  Of course, there is 
the overhead of copying the strings but the allocation can be relatively
cheap.

-----------------------------------------------------------------------
Alex Blakemore                       Internet: blakemore@software.org
Software Productivity Consortium     UUNET:    ...!uunet!software!blakemore
2214 Rock Hill Rd, Herndon VA 22070  Bellnet:  (703) 742-7125

Re: C Strings in Ada?

[Allan Doyle]

Whew, the nesting is getting too deep. I sliced out the parts I want to
comment on...

>>What is the best way to represent C_Strings in Ada?  

>$$	procedure to_c (str : string) 
>$$	is
>$$	  procedure c_routine (addr : system.address);
>$$          pragma interface (C, c_routine);	-- (void) c_routine(s)
>$$						-- char * s;
>$$	  c_string : constant string := str & Ascii.NUL;
>$$	begin
>$$	  c_routine(c_string(c_string'first)'address);
>$$	end to_c;

>I dont think this solution *requires* heap allocation.  A good compiler would 
>be free to use stack space for the C strings in these cases, both for
>the local constant c_string and for the return value.  Of course, there is 
>the overhead of copying the strings but the allocation can be relatively
>cheap.
>
>-----------------------------------------------------------------------
>Alex Blakemore                       Internet: blakemore@software.org
>Software Productivity Consortium     UUNET:    ...!uunet!software!blakemore
>2214 Rock Hill Rd, Herndon VA 22070  Bellnet:  (703) 742-7125

Judging from the replies about heap space, I'm getting a little worried.
Do you guys mean to tell me that it's compiler dependent how to allocate
the 'c_string' constant? This is just the sort of thing that makes me
mistrust Ada for a realtime application that has to run for a long time
without any memory leaks. If I take the worst case assumption that c_string
is being allocated from the heap and add it to the worst case assumption
that my Ada run-time will not be doing garbage collection (perfectly legal,
I understand), then how many of these little beasties can I convert from
Ada to C before I run out of memory?



Allan Doyle                                        adoyle@bbn.com
BBN Systems and Technologies Corporation           (617) 873-3398
70 Fawcett Street,   Cambridge, MA 02138

Re: C Strings in Ada?

[David Kassover]

In article <57245@bbn.BBN.COM> adoyle@vax.bbn.com (Allan Doyle) writes:
...
>
>Judging from the replies about heap space, I'm getting a little worried.
>Do you guys mean to tell me that it's compiler dependent how to allocate
>the 'c_string' constant? This is just the sort of thing that makes me
>mistrust Ada for a realtime application that has to run for a long time
>without any memory leaks. If I take the worst case assumption that c_string
>is being allocated from the heap and add it to the worst case assumption
>that my Ada run-time will not be doing garbage collection (perfectly legal,
>I understand), then how many of these little beasties can I convert from
>Ada to C before I run out of memory?

Perhaps I'm naive.  But isn't management of things like heaps and
stacks and stuff the purview of the underlying hardware and
operating system (if any?)

Under VMS, regardless of language used (well, take my absolutes
as approximately equal to .9944  8-), heap, stack, vm, etc
management can be affected by several parameters pertaining to
the operating system, the user account structure, and the current
hardware configuration.

On the other hand, if you *have* no operating system (your
program lives in an automated teller machine, e.g.) then when you
run out of memory depends on how much you have and how busy your
program was.  If this is a problem, then you must write a garbage
collector yourself (and find room for it in memory  8-), or get
the powers that be to plug in a bigger memory board, or poll the
ATM more frequently.

And furthermore, if what you are writing *is* an operating system
(in the sense of, say, OS 360, MS-DOS, VAX-VMS, VM/CMS, Primos,
or bhog-knows-what), then you *also* might consider writing a
garbage collector, and publishing instructions to writers of
compilers on how to take advantage of it.

But that has nothing, IMHO, to do with Ada.

Or have I missed a point here?
--
David Kassover             "Proper technique helps protect you against
kassover@ra.crd.ge.com	    sharp weapons and dull judges."
kassover@crd.ge.com			F. Collins

Re: C Strings in Ada?

[Allan Doyle]

In article <8446@crdgw1.crd.ge.com>
 kassover@minerva.crd.ge.com (David Kassover) writes:
>In article <57245@bbn.BBN.COM> adoyle@vax.bbn.com (Allan Doyle) writes:
>...
>>
>>Judging from the replies about heap space, I'm getting a little worried.
>>Do you guys mean to tell me that it's compiler dependent how to allocate
>>the 'c_string' constant? This is just the sort of thing that makes me
>>mistrust Ada for a realtime application that has to run for a long time
>>without any memory leaks. If I take the worst case assumption that c_string
>>is being allocated from the heap and add it to the worst case assumption
>>that my Ada run-time will not be doing garbage collection (perfectly legal,
>>I understand), then how many of these little beasties can I convert from
>>Ada to C before I run out of memory?
>
>Perhaps I'm naive.  But isn't management of things like heaps and
>stacks and stuff the purview of the underlying hardware and
>operating system (if any?)
>
>Under VMS, regardless of language used (well, take my absolutes
>as approximately equal to .9944  8-), heap, stack, vm, etc
>management can be affected by several parameters pertaining to
>the operating system, the user account structure, and the current
>hardware configuration.
>
>--
>David Kassover             "Proper technique helps protect you against
>kassover@ra.crd.ge.com	    sharp weapons and dull judges."
>kassover@crd.ge.com			F. Collins

Well, maybe the OS is responsible for managing memory at a macro level, but
certainly not at the level of a few bytes here and there for the kind
of strings we're talking about. The Ada runtime will probably do malloc()
for some hunk of memory when it needs more heap space, and will probably
do a free() call of some sort when it thinks it's done with a large hunk
of memory (but the LRM says it does not have to do so, or at least does
not mention it at all). But if the runtime does not do garbage collection
when my program is done with a few bytes here and there, how will the memory
ever get marked for a free call? 

The OS does not know when the runtime is done with a piece of memory, no
matter how large or small. My point is that the runtime does not neccessarily
even bother to do the space reclamation. So if I write a program that
runs under UNIX in Ada that requires heap space sometimes, I want to be able
to reclaim that heap space. Either explicitly or by knowing that the Ada
runtime will do it for me.

When I am using the Ada "new" keyword, I know full well that I'm creating
potential for garbage. I can control when I call it. I can write my own
memory manager around it. I don't get that control when I need a construct
like

	declare
		c_string : constant string := "foo" & ascii.nul;
	begin
		<stuff>
	end;

If I can't even trust Ada to reclaim the 4 or so bytes used by foo, what
can I trust Ada to do????



Allan Doyle                                        adoyle@bbn.com
BBN Systems and Technologies Corporation           (617) 873-3398
70 Fawcett Street,   Cambridge, MA 02138

Re: C Strings in Ada?

[David Kassover]

In article <57288@bbn.BBN.COM> adoyle@vax.bbn.com (Allan Doyle) writes:
...
>When I am using the Ada "new" keyword, I know full well that I'm creating
>potential for garbage. I can control when I call it. I can write my own
>memory manager around it. I don't get that control when I need a construct
>like
>
>	declare
>		c_string : constant string := "foo" & ascii.nul;
>	begin
>		<stuff>
>	end;

I'll ask for some clarification from the language lawyers (and
others who have experience with specific Ada environments other
than VAX Ada)

but I don't think garbage collection in this instance was ever an
issue.

That is, I have used similar constructs (and rather large ones,
too: potential to store 90000 g_floats) in VAX Ada.  It, so far,
has appeared that when the declared variables go out of scope,
the memory is returned to "the system".

On the other hand, stuff that is created with NEW is often
intended *not* to go out of scope, so unchecked_deallocation is
needed to get rid of it (presumably, *after* the program has
verified that "no one else" still points to it)

And furthermore, I remember having a discussion about this about
a year ago, before I implemented the monster data structure (we
use it to pass potentially large arrays to and from a FORTRAN
program, especially in instances where it is hard for the Ada
code to determine the dimensions of the array.  I was assured
that exhaustion of "heap space" would not be a problem, given
that there was enough heap available for any one scope.  But
again, that may be a "feature" of VAX Ada's way of dealing with it.

--
David Kassover             "Proper technique helps protect you against
kassover@ra.crd.ge.com	    sharp weapons and dull judges."
kassover@crd.ge.com			F. Collins

Re: C Strings in Ada?

[Mike Murphy]

In article <57288@bbn.BBN.COM> adoyle@vax.bbn.com (Allan Doyle) writes:
>When I am using the Ada "new" keyword, I know full well that I'm creating
>potential for garbage. I can control when I call it. I can write my own
>memory manager around it. I don't get that control when I need a construct
>like
>
>	declare
>		c_string : constant string := "foo" & ascii.nul;
>	begin
>		<stuff>
>	end;
>
>If I can't even trust Ada to reclaim the 4 or so bytes used by foo, what
>can I trust Ada to do????

Most Ada compilers will reclaim the space used by an object when it 
exits its scope.  I say "most" because this is not required by the 
semantics of the language, but any good compiler will have this feature, 
as it is needed for large software systems, and it is not too difficult
to implement.  Basically, you emit some code at the end of any blocks 
or statements that use temporary space, to reclaim that space.
This might mean a "free", or it could be something even cheaper 
(e.g. some compilers will put these kind of block-structured temporaries 
on a mark-release stack).  You can code up a little example like the above
to test what your compiler does.  This is not considered to be "real"
garbage-collection, which no Ada compiler I know of does, which requires
searching through memory for dangling pointers.  Instead this is just
an important optimization for a common situation in Ada.  The situation
is more common in Ada than in languages like C because we can have
function calls that return dynamic-sized objects, such as strings,
and these need temporary space.  The reclaiming of the space is helped
by the block-structured nature of its scope (as opposed to the
full-blown garbage collection problem).

-- Mike Murphy
-- UUCP: sun!decwrl!mips!murphy or murphy@mips.com

Re: C Strings in Ada?

[Edward Falis]

you're right: it depends on the compiler and rte implementation. In fairness,
though, several of the more prominent Ada vendors do perform automatic
reclamation (though not garbage collection).  The typical scheme is
to deallocate all objects of the collection type when the access type
goes out of scope.  For compiler-generated temporaries, reclamation 
will occur when the scope creating the tempo is exited, or when the
tempo is no longer required, depending on the thoroughness of the
implementation.  - Ed Falis, Alsys

Re: C Strings in Ada?

[David Emery]

Allan Doyle writes
>If I take the worst case assumption that c_string
>is being allocated from the heap and add it to the worst case assumption
>that my Ada run-time will not be doing garbage collection (perfectly legal,
>I understand), then how many of these little beasties can I convert from
>Ada to C before I run out of memory?

It's not clear to me that you can guarantee with a C compiler that
there is not some compiler-generated heap, either.  Does the C
LANGUAGE guarantee non-heap allocation for a local variable???    Or
does "everyone knows that's how it's done?"

 				dave emery
				emery@aries.mitre.org

Re: C Strings in Ada?

[Allan Doyle]

In article <EMERY.90Jun11135320@scorpio.linus.mitre.org>
 emery@linus.mitre.org (David Emery) writes:
>Allan Doyle writes
>>If I take the worst case assumption that c_string
>>is being allocated from the heap and add it to the worst case assumption
>>that my Ada run-time will not be doing garbage collection (perfectly legal,
>>I understand), then how many of these little beasties can I convert from
>>Ada to C before I run out of memory?
>
>It's not clear to me that you can guarantee with a C compiler that
>there is not some compiler-generated heap, either.  Does the C
>LANGUAGE guarantee non-heap allocation for a local variable???    Or
>does "everyone knows that's how it's done?"
>
> 				dave emery
>				emery@aries.mitre.org


Touche' - I just looked in K&R and found no statement concerning
automatic variables and the memory they occupy. It only states that
the variables "disappear" from scope.

By the way, the example I gave in the previous post:

	declare
		c_string : constant string := "foo" & ascii.nul;

would take up heap in C as well. I really meant 

	proc(foo: string) is
		c_string : constant string := foo & ascii.nul;
	...

which everybody "knows" will go on the stack in C...(sigh)





Allan Doyle                                        adoyle@bbn.com
BBN Systems and Technologies Corporation           (617) 873-3398
70 Fawcett Street,   Cambridge, MA 02138

Re: C Strings in Ada?

[Jeff Bartlett]

In article <920025@hpclapd.HP.COM>, defaria@hpclapd.HP.COM (Andy DeFaria) writes:
> >/ hpclapd:comp.lang.ada / emery@D74SUN.MITRE.ORG (David Emery) / 10:21 am  Jun  6, 1990 /
> >>What is the best way to represent C_Strings in Ada?  
> >
> >	procedure to_c (str : string) 
> >	is
> >	  procedure c_routine (addr : system.address);
> >          pragma interface (C, c_routine);	-- (void) c_routine(s)
> >						-- char * s;
> >	  c_string : constant string := str & Ascii.NUL;
> >	begin
> >	  c_routine(c_string(c_string'first)'address);
> >	end to_c;

> ... my critical concerns: What about  the overhead incurred by
> having  to call the  heap manager to allocate a  new string just  to append
> ASCII.NUL so  that the C routine I'm   calling  will be  able to handle  it
> properly. ...

A good compiler should grow the stack by (str'length + 1 + string_descriptor)
then copy 'str' and the NUL into the area.  It would also fill in the
new string_descriptor for 'c_string' from the information in 'str's descriptor
and the additional byte.  (A smart compiler may not even allocate space for
the new descriptor, keeping the information in registers).

Constant strings are a good 'trick'. Such as:

    ...
	str : string(1..10);
	N   : natural;
    begin
	...

	-- a subroutineless call like above
	declare
           s : constant string := str & ascii.nul;
        begin
           c_routine( s(s'first)'address );
        end;

	-- remove the leading space supplied by 'image.
	declare
	   s : constant string := integer'image(N);
        begin
           text_io.put_line("Activity on PE" & s(s'first+1..s'last) );
        end;

	-- figuring out how much of a buffer to overwrite
        declare
           s : constant string := function_that_returns_a_string(j);
        begin
           line(line'first..line'first+s'length-1) := s;  -- result used twice
        end;

> Another, problem that you haven't addressed  is that  of the representation
> of a string in a record.  Should it be  and  Ada access to string or should
> it be the string itself.  Or should it be a C string (char *)?

It depends on what operations need to be performed on it.  I'll leave this for
someone else.  Don't forget that you can:

	type s_ptr is access string;
        p : s_ptr;
    begin
        ...
	-- this will call the function, allocate space for the result, and
        -- initialize the area with the result.
        p := new string'( ada_function_that_returns_a_string );
        ...
	text_io.put_line("answer was '" & p.all & "'");


If you are paranoid about the Ada run-time heap manager forgetting to free
the space pointed to by 'p', you can instantate a new UNCHECKED_DEALLOCATION.

Hope this helps,

Jeff Bartlett
Research Engineer, Center for Digital Systems Research
Research Triangle Institute, RTP NC.
jb@rti.rti.org     mcnc!rti!jb     rti!jb@mcnc.org     (919)-541-6945

PS: The code above was only compiled with a chemical computer. ;-)

Re: C Strings in Ada?

[Andy DeFaria]

One of my concerns about coverting Ada Strings to C Strings  was the amount
of overhead involved in allocating heap space.  Dave  Emery stated that the
compiler should  not allocated any  heap space  for a  local variable -  it
should be placed in the stack:

declare
   C_STRING : constant STRING := STRING_PARAM & ASCII.NUL;
begin
   -- call C routine
end;

My understanding is that the compiler would allocate space on the stack for
this variable if the size of STRING_PARAM can be determined at compile time
not at run time.  Since STRING_PARAM is being passed into my routines it is
not  known, at compile time,  how big   the  STRING_PARAM will be (it could
theoretically (sp?) be INTEGER'LAST bytes long!!  Assuming a 32 bit integer
size  this could be gigantic  and with  some  architectures  stack space is
limited and heap space is more plentifull) so  the compiler might determine
that it is better to put this variable on the heap  instead.  This does not
mean  that the compiler   is  faulty.   This also  might   help  facilitate
procedure cleanup.

Also, no one has  address  my other  concern about  how to represent  these
strings in structures such as:

struct data_record {
   char *path;
   int  path_length;
   char *name;
   int  name_length;
}

Re: C Strings in Ada?

[David Emery]

defaria@hpclapd.hp.com writes
>My understanding is that the compiler would allocate space on the stack for
>this variable if the size of STRING_PARAM can be determined at compile time
>not at run time.  Since STRING_PARAM is being passed into my routines it is
>not  known, at compile time,  how big   the  STRING_PARAM will be (it could
>theoretically (sp?) be INTEGER'LAST bytes long!!  

There is no requirement (in Ada or any other language) that only
objects who size is static at compile-time be allocated off the stack.
The requirement, instead, is that the size of the object be STATIC at
runtime.  The size of STRING_PARAM is known when the stack frame for
the block is built.  For instance, if STRING_PARAM is 7 characters
long, then a string of length 7 is allocated off the stack.  Almost
any block-structured language can do this (including C and Pascal).
To insure that the object being declared (C_STRING) remains static, it
is declared as a constant.  

Ada provides substantial support for types and subtypes whose size is
not known until runtime.  There are some things you can't do with
them, but in general storage allocation is not a problem.  That is
because all objects in Ada are required to be constrained, either with
a fixed size, or with a maximum size.  In the case of variant records
with defaults, the maximum size is determinable based on the range of
values of the discriminant.  

There is always the problem with overflowing either stack or heap.  If
you have a string where 'LENGTH = INTEGER'LAST, I doubt that it will fit
anywhere in main memory, and you'll get STORAGE_ERROR long before you
try to append a ASCII.NUL to it and pass it to C.

				dave emery
				emery@aries.mitre.org

Re: C Strings in Ada?

[Mike Murphy]

In article <920026@hpclapd.HP.COM> defaria@hpclapd.HP.COM (Andy DeFaria) writes:
>Also, no one has  address  my other  concern about  how to represent  these
>strings in structures such as:
>
>struct data_record {
>   char *path;
>   int  path_length;
>   char *name;
>   int  name_length;
>}

It seems to me that the simple solution is to just define a c_string
type which is an access to a constrained string, and then some routines
to convert strings to c_strings and vice-versa.  Then you define your
records to match the C structures:
	type data_record is record
		path 		: c_string;
		path_length 	: integer;
		name 		: c_string;
		name_length 	: integer;
	end record;
The cost of converting strings to c_strings is probably not as bad as you 
imagine, depending on your application (e.g. chances are you will only
convert string to c_string once, then do many calls to C routines with
the c_string structures).

BTW, Verdix uses such an approach in their UNIX interfaces (there is a
c_strings package in the standard library).

-- Mike Murphy
-- UUCP: sun!decwrl!mips!murphy or murphy@mips.com

Re: C Strings in Ada?

[stt]

Re: C Strings in Ada
Please listen to Mike Murphy.  He knows of what he speaks!

In particular, many compilers do *not* use the heap for
objects of dynamic size.  Instead, they use a mark/release discipline
on a stack, either the primary stack or a secondary stack.

Secondly, despite David Emory's appropriate warning, *most* Ada
compilers will treat access-to-*constrained*-string as a simple
address pointing directly at the characters.  You will still
have to worry about the null terminator, since Ada is presuming
the pointed-to string is quite long.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138