Let's define our own NULL

Dave Hammond daveh at marob.MASA.COM
Mon Jun 27 22:35:55 AEST 1988


In article <11326 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
>[...stuff deleted...]
>  Obviously there are ill-written programs which expect NULL to be an
>int, even though the term "NULL pointer" is used in K&R, even in the
>index. These programs may break in some obscure ways when a true pointer
>is used, so my solution is not perfect.
>
>  For all the people who are going to post saying "ignore the
>brain-damaged PC," stay in school. People who write software for a
>living can't ignore ten million possible sales, or the ability to run on
>really cheap units inhouse. Anyone who lives in that commercial
>environment must live with it, and anyone who wants to write postable
>code in general should consider all current and future targets.

Here, here! You can not image the volumes of code I've had to modify when
porting programs from larger machines to the 80x86 family. Most ends up
with a basic one-line fix:

    if (ptr==NULL)
        return(error_value);

Sure, its an easy fix, but making a large program just to find out I get
a "segmentation violation" (or whatever) and core dump is a real pain.
BTW- Don't think that the "large  model" C library routines handle this
situation. Passing NULL to any of the str*, *printf or ato* families will
bomb too. (You'd think Microsoft would *know* about passing zero to far
addresses and deal with it :-)

Dave Hammond
UUCP:   ...!marob!daveh
--------------------------------



More information about the Comp.lang.c mailing list