Date: Tue, 4 Aug 1998 11:46:55 +0200 (MET DST) From: Hans-Bernhard Broeker To: "Gurunandan R. Bhat" cc: djgpp AT delorie DOT com Subject: Re: Null page Protection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 3 Aug 1998, Gurunandan R. Bhat wrote: > But aren't all DJGPP images loaded in extended memory where the only > thing you can clobber in the null page is your own code. Your own code is not in the null page, with DJGPP. If it were, it couldn't ever be run, as null page protection disallows all access to the null page, even for reading code from it. > What advantages > does it serve in these situations, if any. It detect (some) blatant bugs in your code, automatically. Dereferencing a NULL pointer is explicitly disallowed by the ANSI/ISO C standard. In the words of the standard, you get 'undefined behaviour'. That means that, depending on whatever external parameter comes to mind (up to and including phase of the moon, and/or the Dow/Jones index :-), the program is allowed to do *everything* it likes: kill your machine, overwrite itself with zeroes, write a 'I plan to kill you' mail to Mr. Bill Clinton, whatever. It may even work as expected, if you're *very* lucky. But even in the latter case, your program still does have a bug, which you ought to fix. DJGPP helps you by not ignoring this potentially disastrous error. Instead, it kills your program, or throws you into the debugger, if you're running the program under debugger control. Shortly: warnings, error messages and reproducible crashes are among the best friends a software developer can have. Try to avoid them, but not by disabling them, but by fixing the cause, instead, and you'll end up with a nice stable program. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.