Referencing through a null pointer

Bob Larson blarson at skat.usc.edu
Tue Apr 26 18:27:54 AEST 1988


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

In article <2730 at bsu-cs.UUCP> dhesi at 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 at Ecla.Usc.Edu	blarson at skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%fns1 at ecla.usc.edu
			oberon!fns1!info-prime-request



More information about the Comp.lang.c mailing list