Mail Archives: djgpp/1998/08/04/05:51:48
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.
- Raw text -