home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / modula2 / 1094 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!taligent!apple!lins
  2. From: lins@Apple.COM (Cheryl Lins)
  3. Newsgroups: comp.lang.modula2
  4. Subject: Re: Oberon question
  5. Summary: answer
  6. Keywords: Oberon, pointers, NEW
  7. Message-ID: <71886@apple.Apple.COM>
  8. Date: 1 Sep 92 16:42:32 GMT
  9. References: <1992Sep1.082031.17228@cs.joensuu.fi>
  10. Organization: Apple Computer Inc., Cupertino, CA
  11. Lines: 24
  12.  
  13. In article <1992Sep1.082031.17228@cs.joensuu.fi> jpussi@cs.joensuu.fi (Jarmo Pussinen) writes:
  14. >In some paper I read that in Oberon, all pointer variables are
  15. >initialised to NIL. Now I would like to know if this means that
  16. >also pointer fields in dynamically (with NEW) allocated records
  17. >or in static records are initialised to NIL. 
  18. >
  19. >In short are pointers always either NIL or valid pointers and
  20. >not garbage pointers. May it vary between implementations?
  21.  
  22. I lobbied for explicit mention in the language report that all pointers are
  23. initialized to NIL. Unfortunately, that didn't happen. ETH did not consider
  24. it necessary. Any implementation that does not automatically initialize all
  25. pointers is going to violate Oberon's type safety. So it shouldn't vary
  26. between implementations.
  27.  
  28. For dyanmically allocated storage, to the programmer such storage should
  29. always look like virgin memory when NEW is called. The fact the automatic
  30. storage management (ie garbage collection) can occur should not be something
  31. you have to program around or be aware of.
  32.  
  33.  
  34. -- 
  35. Cheryl Lins, Apple Computer, Inc. Oberon-2 Paladin  lins@apple.com
  36. "Oppression breeds violence" - Front Line Assembly
  37.