home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.pascal:6827 comp.object:4297
- Newsgroups: comp.lang.pascal,comp.object
- Path: sparky!uunet!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!news.funet.fi!network.jyu.fi!sakkinen
- From: sakkinen@jyu.fi (Markku Sakkinen)
- Subject: Re: BP/TP OOP is missing something...
- Message-ID: <1992Nov23.070908.141@jyu.fi>
- Organization: University of Jyvaskyla, Finland
- References: <1992Nov18.104536.9985@jyu.fi> <dmurdoch.284.722095796@mast.queensu.ca> <1992Nov20.135804.8752@ida.liu.se>
- Date: Mon, 23 Nov 1992 07:09:08 GMT
- Lines: 29
-
- In article <1992Nov20.135804.8752@ida.liu.se> c89ponga@odalix.ida.liu.se (kand. Pontus Gagge) writes:
- > ...
- >>>I would guess that good Pascal implementation may also initialise
- >>>pointer variables to NIL so that using them before assignment
- >>>will not cause catastrophic effects.
- >
- >>On a PC in "real" mode, NIL is likely the most catastrophic value to
- > ^^^^^^^^^^^^
- >>initialize a pointer to :-). TP doesn't initialize pointers, but at
- >>least one TP clone (Pascal+ from Stony Brook) does.
- >
- >In case someone misses the implicit irony, let me point out the obvious:
- >the best errors are those that generate the worst cataclysms. This makes
- >them sort of hard to miss...
-
- IMO, it is a bad and unsafe Pascal compiler that does not support
- the run-time detection of dereferencing NIL, even as an option.
- I realise that such detection is too expensive on some unsophisticated
- processor architectures to be always done.
-
- ----------------------------------------------------------------------
- Markku Sakkinen (sakkinen@jytko.jyu.fi)
- SAKKINEN@FINJYU.bitnet (alternative network address)
- Department of Computer Science and Information Systems
- University of Jyvaskyla (a's with umlauts)
- PL 35
- SF-40351 Jyvaskyla (umlauts again)
- Finland
- ----------------------------------------------------------------------
-