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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,3488d9e5d292649f X-Google-Attributes: gid101deb,public X-Google-ArrivalTime: 2003-02-21 05:46:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed-east.nntpserver.com!nntpserver.com!news-west.rr.com!cyclone.nyroc.rr.com!cyclone-out.nyroc.rr.com!twister.nyroc.rr.com.POSTED!53ab2750!not-for-mail Message-ID: <3E56203D.BD1F694@yahoo.com> From: Peter Flass X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.pl1,comp.lang.ada Subject: Re: status of PL/I as a viable language References: <3E554AF4.C8F0EF2E@yahoo.com> <819A9E0CA1094B88.6E582670555DCA33.F06C4B2BCD076570@lp.airnews.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 21 Feb 2003 13:46:10 GMT NNTP-Posting-Host: 24.194.50.82 X-Complaints-To: abuse@rr.com X-Trace: twister.nyroc.rr.com 1045835170 24.194.50.82 (Fri, 21 Feb 2003 08:46:10 EST) NNTP-Posting-Date: Fri, 21 Feb 2003 08:46:10 EST Organization: Road Runner Xref: archiver1.google.com comp.lang.pl1:4388 comp.lang.ada:34339 Date: 2003-02-21T13:46:10+00:00 List-Id: "John R. Strohm" wrote: > > "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". Well, not "always", remember some O/S code has to access virtual address 0, but almost always. > > 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. Right, except that dreferencing a null pointer is an *error*, and should not occur in normal code. Better to let the hardware trap it for the 1 in 10**6 times it may occur than execute a lot of useless checking every time you run the program. Just so someone checks. As for granularity, I'm reading this on comp.lang.pl1 and not comp.lang.ada. PL/I provides the tools to handle this, as long as the programmer puts a litt;e thought into the design.