From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 101deb,3488d9e5d292649f
X-Google-Attributes: gid101deb,public
X-Google-Thread: 103376,e6a2e4a4c0d7d8a6
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-02-20 14:34:47 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!xmission!news-out.spamkiller.net!propagator2-maxim!news-in.spamkiller.net!feed.newsfeeds.com!newsfeed.onecall.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.pl1,comp.lang.ada
Subject: Re: status of PL/I as a viable language
Date: 20 Feb 2003 16:34:43 -0600
Organization: Berbee Information Networks Corporation
Message-ID: <oUDTUaOQ$qt1@eisner.encompasserve.org>
References: <mHZ0a.42983$jM5.108891@newsfeeds.bigpond.com>
 <nRg1a.190899$HG.32437469@news4.srv.hcvlny.cv.net>
 <3E51908E.9CCA3412@adaworks.com>
 <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net>
 <3E51ABCE.5491B9A2@adaworks.com> <b2spe6$p23$1@helle.btinternet.com>
 <3E5273DE.2050206@cox.net> <3E531E6F.BDFB2599@adaworks.com>
 <3E546C45.4010406@cox.net> <3E54F926.441D5BB5@adaworks.com>
 <1045763933.848350@master.nyc.kbcfp.com>
 <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net>
 <3E554AF4.C8FOrganization: LJK Software
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 1045780410 26939 192.135.80.34 (20 Feb 2003
 22:33:30 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Thu, 20 Feb 2003 22:33:30 +0000 (UTC)
Xref: archiver1.google.com comp.lang.pl1:4377 comp.lang.ada:34316
Date: 2003-02-20T16:34:43-06:00
List-Id: <comp.lang.ada>

In article <3E554AF4.C8F0EF2E@yahoo.com>, Peter Flass <peter_flass@yahoo.com> writes:
> "John R. Strohm" wrote:
>> The last bug I found and fixed at my last employer was a null pointer
>> access.  That company has an internal coding policy that pointers will
>> ALWAYS be tested for null before being dereferenced.  
> 
> I would submit that this should be done by hardware, not software (i.e.
> location 0, assuming null is 0) should be fetch-protected from

Typically it is, and an exception will be thrown.

Coding standards to test first typically include the notion that
some reasonable action should be taken in lieu of the fetch.

> everywhere but a few O/S routines.  Anything else is a colossal waste of
> computing resources.

Once you are handling exceptions, performance is not very important,
since exceptions are, by definition, not supposed to be the normal
course of events.