home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / ada / 3798 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.7 KB  |  68 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!noc.near.net!inmet!spock!stt
  3. From: stt@spock.camb.inmet.com (Tucker Taft)
  4. Subject: Re: Implementation or LRM driven
  5. Message-ID: <1992Dec22.144742.12024@inmet.camb.inmet.com>
  6. Sender: news@inmet.camb.inmet.com
  7. Nntp-Posting-Host: spock
  8. Organization: Intermetrics Inc, Cambridge MA
  9. References: <1992Dec22.124210.7098@evb.com>
  10. Date: Tue, 22 Dec 1992 14:47:42 GMT
  11. Lines: 55
  12.  
  13. In article <1992Dec22.124210.7098@evb.com> brandon@evb.com (Brandon) writes:
  14.  
  15. >I have been trying to determine any rules either in AI's, LRM or other sources
  16. >in how a compiler is permitted to 
  17. >allocate/deallocate return values for functions.
  18. >
  19. >When the information is returned from a function some space must be allocated, 
  20. >and placed on the call stack.  In the 
  21. >case of a function returning a non-scalar
  22. >when MUST that space be deallocated (or can an implemenation lose it).  I've
  23. >seen many cases and can not find a specific rule.
  24.  
  25. As in essentially all programming languages, the management of stack
  26. space and other storage used for local variables and other temporaries
  27. is entirely implementation dependent.  There are no rules
  28. the the Ada 83 RM that require any particular strategy for management
  29. of this storage space.  
  30.  
  31. For Ada 9x, there will be a Systems and Real-Time Programming Annexes 
  32. where we intend to get somewhat more concrete about implementation 
  33. requirements in this and other areas.  In particular, there will be
  34. a requirement to document where "heap" storage is allocated implicitly
  35. (as opposed to explicitly via a "new").
  36.  
  37. >As a second question, in this example:
  38. >    subtype MYSTR is STRING(1..50);
  39. >    function Str(X: in INTEGER) return MYSTR;
  40. >
  41. >    X: BUFFER(1..200);
  42. >    X := Str(1) & Str(2) & Str(3) & Str(4);    <---- here
  43. >
  44. >    During the "&" operations being called is the memory being
  45. >    used 50+50+100+50+150+50+200 = 650 allowably, unavoidable, or
  46. >    completely implementation dependent.
  47.  
  48. Again, there are no requirements on the management of storage
  49. for temporaries.  For dynamic-sized temporaries, some Ada compilers 
  50. use the heap, some use a "secondary" mark/release stack, and some use 
  51. the equivalent of C's "alloca" which extends the "primary" stack.
  52. Some reclaim this storage at the end of the statement, some at
  53. the end of the block, some at the end of the subprogram, and some
  54. have bugs and lose track of some of it under certain circumstances.
  55.  
  56. >Any references would be appreciated
  57.  
  58. Stay tuned for Ada 9X.  Nothing much exists on Ada 83.
  59.  
  60. >Office Automation, n.:
  61. >    The use of computers to improve efficiency by removing anyone
  62. >    you would want to talk with over coffee.
  63.  
  64. S. Tucker Taft    stt@inmet.com
  65. Ada 9X Mapping/Revision Team
  66. Intermetrics, Inc.
  67. Cambridge,  MA  02138
  68.