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