Xref: utzoo comp.unix.wizards:8043 comp.lang.c:9652
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: Referencing through a null pointer
Message-ID: <8727@oberon.USC.EDU>
Date: 26 Apr 88 08:27:54 GMT
References: <4729@cup.portal.com> <1988Apr24.092740.8673@utzoo.uucp> <50676@sun.uucp> <2730@bsu-cs.UUCP>
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Followup-To: comp.lang.c
Organization: USC AIS, Los Angeles
Lines: 25

[followups redirected to comp.lang.c, this isn't a unix-specific issue.]

In article <2730@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>So long as your memory management hardware is trapping references
>through a null pointer and printing an error message, how about
>allowing the user to set a switch that will cause such illegal trapped
>references to be handled by an emulation routine that will cause a zero
>to be returned and continue execution?

Unfortunatly, this would only encorage the develepment of buggy software,
and slow the fixing of existing buggy software.

I propose adding a flag to executables that tells the system how to
handle null pointer dereferences.  Normally, they should trap to a
fatal error procedure, but an option to trap to a routine that does a
sleep(1), sets the process priority to the lowest possible, and then
returns a 0 of the correct type to the buggy program might be useful
as a porting aid.  (Why should a background process be considered less
important that continuing a known buggy program?)  The reduced speed
should be enough so software vendors can't get away distributing broken
programs.
--
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%fns1@ecla.usc.edu
			oberon!fns1!info-prime-request