🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13030

Re: catering to bad code

#13030
From: guy
Date: Fri, 20 Feb 1987 21:04
46 lines
2821 bytes
>As a part time computer user (as well as part time architect), I find
>any tool or operating system that "crashes disgustingly" to be highly
>wasteful of my time.

So do I.  That's why I agree 100% with Firth that programs that
dereference null pointers should "crash disgustingly" on all
implementations - so that they crash in the developer's lap, not
mine.

>Much of the software that I use was written by somebody else at another site.
>Getting him to fix his questionable practice may not be as easy as you
>indicate.

That's entirely beside the point.  There is no *guarantee* that the
code would work correctly even if you *did* permit dereferencing of
null pointers!  If you don't permit dereferencing null pointers, a
program that tries to dereference a null pointer is guaranteed to
fail.  If you do, the program might work, but then again it might fail in
some mysterious way, and the consequences of the failure discovered
much later (when it might be *too* late).

This is *not* just ivory-tower speculation.  See Howard Landman's
article <436@cpocd2.UUCP>.

>The other issue here is that the differences may not show up at compile
>time.  You have now introduced a "bug" into the newly installed
>software.

This resembles an annoying practice called "blaming the victim".  The
compiler/OS authors didn't introduce *any* bug whatsoever!  The bug was
in the original code; the author of that code was just lucky in that
their code ran with no obvious visible symptoms.  

>Not only will a lot of user time be wasted, but a lot of system or
>applications programmer time will be spent chasing down this
>bug.  How many guaranteed bugs are you willing to generate as a systems
>programmer?

What is this "guaranteed bugs" stuff?  If it's guaranteed that
some person will put out code that will fail if you can't dereference
null pointers, then *that person* generated that bug, not the people
who created the implementation that forbids dereferencing null
pointers!  The person in question should be re-educated, using a
salary continuation program as incentive, if necessary.  Go yell at
him or her for the time you spent chasing down his or her bug, not at
the compiler/OS implementor!
Technical Details
Message-ID: <13755@sun.uucp>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
References: <14833@amdcad.UUCP> <554@aw.sei.cmu.edu.sei.cmu.edu> <975@unc.unc.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.arch
Subject: Re: catering to bad code
Message-ID: <13755@sun.uucp>
Date: Fri, 20-Feb-87 16:04:16 EST
Article-I.D.: sun.13755
Posted: Fri Feb 20 16:04:16 1987
Date-Received: Sat, 21-Feb-87 16:01:48 EST
References: <14833@amdcad.UUCP> <554@aw.sei.cmu.edu.sei.cmu.edu> <975@unc.unc.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 46