home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v1 / text0048.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  2.4 KB  |  49 lines
  1. ----------------------------------------------------------------------
  2.  
  3. From: seismo!BBN-LABS-B.ARPA!dan
  4. To: ut-sally!BBN-LABS-B.ARPA!std-unix
  5. Subject: Re: Storage allocators
  6. Date: 05 Aug 85 12:30:18 EDT (Mon)
  7.  
  8. Much as I like alloca() in theory, I have to agree with Doug Gwyn that it is
  9. not always implementable--at least, if you are starting with the runtime
  10. environment already designed.  Alloca() is a LANGUAGE feature, not a library
  11. feature; it just happens that on many UNIX machines it is possible to add it to
  12. the library and slip it past the compiler as long as you don't try to use it
  13. too hard.  On many systems, if you do
  14.  
  15.     routine_with_args(arg1, arg2, arg3, ..., alloca(100), argN,...);
  16.  
  17. the alloca() will screw things up completely because the arguments before and
  18. after it were pushed on the stack--that is, are SP-relative--and alloca() has
  19. munged the SP.  Sufficiently complex expressions can also cause this problem.
  20. Unless alloca() is known to the compiler it usually cannot be implemented
  21. correctly.
  22.  
  23. However, I don't understand Doug's comment about it encouraging sloppy
  24. programming practice.  Alloca() provides the programmer with the ability to
  25. declare automatic variables whose size is determined at runtime rather than
  26. compile time; thus the size can reflect the size of input data, which is GOOD
  27. programming practice.  If the makers of UNIX had had alloca() when they did
  28. execvp(), they would not have (a) relied on the existence of array[-1], or (b)
  29. assumed that there would not be more than 200 values in the array (as different
  30. versions of that library routine did).  I don't think anyone would argue that
  31. the use of alloca here would have resulted in sloppier code!  The only
  32. alternative, if you want to be a good programmer, is to use malloc(), which is
  33. relatively slow and quite clumsy.  I have never subscribed to the point of view
  34. that not having to explicitly allocate and free each variable is "sloppy
  35. programming practice"; that's what auto vars are, after all.
  36.  
  37.     Dan Franklin
  38.  
  39. ------------------------------
  40.  
  41. Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
  42. Submissions-To:    ut-sally!std-unix    or std-unix@ut-sally.ARPA
  43. Comments-To: ut-sally!std-unix-request    or std-unix-request@ut-sally.ARPA
  44. UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
  45. Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
  46.  
  47. Volume-Number: Volume 1, Number 49
  48.  
  49.