Mail Archives: djgpp/1995/05/09/04:39:23
> My modified version compiles with Borland C++ (version 4.5) and with
> djgpp (from the archive gcc263bn.zip), but the djgpp version always
> crashes at runtime with the message:
>
> Segmentation violation in pointer 0x00000000 at ...
>
>
> exception 14 (0xe) occurred, error code=0
>
> I have traced this in at least two cases. The first occurs when the
> string argument to atof() is NULL. The second occurs when a NULL pointer
> is dereferenced. (Ultimately, these two errors are the same, since atof()
> attempts to dereference the NULL argument to read the string).
>
> When compiled with the Borland compiler, the program just runs right
> through these sections. In fact, atof((char *) NULL) returns 0.0
> when compiled with Borland C++ 4.5.
Borland C generates real-mode programs, where you don't have almost ANY
protection against dereferncing a null pointer (or even against loading
your registers with garbage and jumping into the blue, for that matter).
DJGPP just did you a great service in that it found a severe bug in the
program that somebody trusts to produce meaningful results. How can
anybody ask for a facility to turn this great feature off?? How can you
trust the results of a simulation program after you learn that it uses
garbled data (produced by dereferencing a null pointer) from time to time???
I worked with simulations for several years. I remember that any suspicion
about the program(s) I used, even a compile-time warning, would immediately
invalidate its output until such time as that problem is resolved.
I say you should hunt the bug in the program which causes a null pointer
to be passed, and eliminate it. If I were you, I won't be satisfied with
a wrapper function solution, as suggested by Aaron Ucko, but would try very
hard to understand why that null pointer is born in the first place.
P.S. I apologize for somewhat steamy style, I just couldn't believe my eyes
when I've read your posting.
- Raw text -