home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / pascal / 6830 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  2.3 KB
  1. Xref: sparky comp.lang.pascal:6830 comp.object:4298
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!doc.ic.ac.uk!uknet!mcsun!sunic!kth.se!dront.nada.kth.se!d85-jmh
  3. From: d85-jmh@dront.nada.kth.se (Jan-Olof Hendig)
  4. Newsgroups: comp.lang.pascal,comp.object
  5. Subject: Re: BP/TP OOP is missing something...
  6. Message-ID: <1992Nov23.102238.18624@kth.se>
  7. Date: 23 Nov 92 10:22:38 GMT
  8. Sender: usenet@kth.se (Usenet)
  9. Organization: Royal Institute of Technology, Stockholm, Sweden
  10. Lines: 38
  11. Nntp-Posting-Host: dront.nada.kth.se
  12.  
  13. In article <1992Nov23.070908.141@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
  14. >In article <1992Nov20.135804.8752@ida.liu.se> c89ponga@odalix.ida.liu.se (kand. Pontus Gagge) writes:
  15. >> ...
  16. >>>>I would guess that good Pascal implementation may also initialise
  17. >>>>pointer variables to NIL so that using them before assignment
  18. >>>>will not cause catastrophic effects.
  19. >>
  20. >>>On a PC in "real" mode, NIL is likely the most catastrophic value to 
  21. >>                                                ^^^^^^^^^^^^
  22. >>>initialize a pointer to :-).  TP doesn't initialize pointers, but at 
  23. >>>least one TP clone (Pascal+ from Stony Brook) does.
  24. >>
  25. >>In case someone misses the implicit irony, let me point out the obvious:
  26. >>the best errors are those that generate the worst cataclysms. This makes
  27. >>them sort of hard to miss...
  28. >
  29. >IMO, it is a bad and unsafe Pascal compiler that does not support
  30. >the run-time detection of dereferencing NIL, even as an option.
  31. >I realise that such detection is too expensive on some unsophisticated
  32. >processor architectures to be always done.
  33. >
  34. >----------------------------------------------------------------------
  35. >Markku Sakkinen (sakkinen@jytko.jyu.fi)
  36. >       SAKKINEN@FINJYU.bitnet (alternative network address)
  37. >Department of Computer Science and Information Systems
  38. >University of Jyvaskyla (a's with umlauts)
  39. >PL 35
  40. >SF-40351 Jyvaskyla (umlauts again)
  41. >Finland
  42. >----------------------------------------------------------------------
  43.  
  44. Being able to detect NIL pointer dereferencing is a good reason to upgrade
  45. to BP7. You 'just have to recompile' your programs with target set to 
  46. 'Protected', and then run them. All NIL pointers that are dereferenced will
  47. generate Runtime error 216, as will most illegal pointer operations, like
  48. for instance using a noninitialized pointer. Protected mode has its benefits.
  49.  
  50. Jan-Olof
  51.