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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!snorkelwacker!mit-eddie!bbn.com!adoyle From: adoyle@bbn.com (Allan Doyle) Newsgroups: comp.lang.ada Subject: Re: C Strings in Ada? Message-ID: <57288@bbn.BBN.COM> Date: 11 Jun 90 19:48:43 GMT References: <920024@hpclapd.HP.COM> <920025@hpclapd.HP.COM> <1304@software.software.org> <57245@bbn.BBN.COM> <8446@crdgw1.crd.ge.com> Sender: news@bbn.com Reply-To: adoyle@vax.bbn.com (Allan Doyle) Organization: Bolt Beranek and Newman Inc., Cambridge MA List-Id: 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 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