From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!defaria@hpclapd.HP.COM
From: defaria@hpclapd.HP.COM (Andy DeFaria)
Newsgroups: comp.lang.ada
Subject: Re: C Strings in Ada?
Message-ID: <920026@hpclapd.HP.COM>
Date: 11 Jun 90 22:39:00 GMT
References: <920024@hpclapd.HP.COM>
Organization: Hewlett-Packard Calif. Language Lab
List-Id: <comp.lang.ada>

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;
}