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 15:45:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.airnews.net!cabal12.airnews.net!usenet From: "John R. Strohm" Newsgroups: comp.lang.pl1,comp.lang.ada Subject: Re: status of PL/I as a viable language Date: Thu, 20 Feb 2003 17:30:45 -0600 Organization: Airnews.net! at Internet America Message-ID: <819A9E0CA1094B88.6E582670555DCA33.F06C4B2BCD076570@lp.airnews.net> X-Orig-Message-ID: References: <3E554AF4.C8F0EF2E@yahoo.com> X-A-Notice: References line has been trimmed due to 512 byte limitation Abuse-Reports-To: abuse at airmail.net to report improper postings NNTP-Proxy-Relay: library1-aux.airnews.net NNTP-Posting-Time: Thu Feb 20 17:43:46 2003 NNTP-Posting-Host: !`F"`1k-YHOq"o4 (Encoded at Airnews!) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.pl1:4378 comp.lang.ada:34318 Date: 2003-02-20T17:30:45-06:00 List-Id: "Peter Flass" wrote in message news:3E554AF4.C8F0EF2E@yahoo.com... > "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 > everywhere but a few O/S routines. Anything else is a colossal waste of > computing resources. On just about every machine I've ever dealt with, dereferencing a null pointer throws a hardware trap. Dereferencing a null pointer is ALWAYS an error. It may be a case of "This pointer should NEVER be null" or it may be a case of "OK, there is no existing entry for this object, so we have to create a new one". Catching a hardware trap and recovering from it is almost always MUCH more expensive than checking a pointer for null. It gets seriously ugly if you are trying to control the granularity of the trap catching code, so you know that an exception handled here could only be a pointer fault.