Avoiding dereference of NULL pointer

Discussion in 'C Programming' started by Tony Jackson, Dec 15, 2007.

  1. Tony Jackson

    Tony Jackson Guest

    Hi

    I'm quite new to C programming - I have more of a Java background: maybe
    someone here can advise me.

    I'm nearly finishing a little program but it has some hard-to-find bugs
    that basically lead to a couple pointers sometimes being NULL at the
    wrong time. As it stands the program just bombs out when it tries to
    dereference the NULL, which obviously isn't good (especially when it
    happens with the customer looking on!!).

    I don't think there's any serious problem to worry about, and what I'd
    like to do is be able to ignore the dereference attempt and just carry
    on - probably the next time round the loop the pointer will be OK. In
    Java, I'd put a try block around the main loop, and if we catch an
    exception then just jump back to the start of the main loop. What's the
    corresponding thing in C?

    Thanks!
    Tony Jackson, Dec 15, 2007
    #1
    1. Advertising

  2. Tony Jackson

    pete Guest

    Tony Jackson wrote:
    >
    > Hi
    >
    > I'm quite new to C programming - I have more of a Java background: maybe
    > someone here can advise me.
    >
    > I'm nearly finishing a little program but it has some hard-to-find bugs
    > that basically lead to a couple pointers sometimes being NULL at the
    > wrong time. As it stands the program just bombs out when it tries to
    > dereference the NULL, which obviously isn't good (especially when it
    > happens with the customer looking on!!).
    >
    > I don't think there's any serious problem to worry about, and what I'd
    > like to do is be able to ignore the dereference attempt and just carry
    > on - probably the next time round the loop the pointer will be OK. In
    > Java, I'd put a try block around the main loop, and if we catch an
    > exception then just jump back to the start of the main loop.
    > What's the
    > corresponding thing in C?


    Put code in place to prevent
    the deference attempt of the null pointer, instead.

    --
    pete
    pete, Dec 15, 2007
    #2
    1. Advertising

  3. Tony Jackson

    Tony Jackson Guest

    > Put code in place to prevent
    > the deference attempt of the null pointer, instead.


    Thanks for the reply. That would mean testing for NULL at every pointer
    dereference which would be a lot of extra code - I was looking for a
    catch-all solution. (Unfortunately I've already experienced several
    different places where the program tries to dereference NULL, and who
    knows how many others there are lurking in the background...)
    Tony Jackson, Dec 15, 2007
    #3
  4. Tony Jackson

    Guest

    On Dec 15, 10:52 am, Tony Jackson <>
    wrote:
    > Hi
    > I'm nearly finishing a little program but it has some hard-to-find bugs
    > that basically lead to a couple pointers sometimes being NULL at the
    > wrong time. As it stands the program just bombs out when it tries to
    > dereference the NULL, which obviously isn't good (especially when it
    > happens with the customer looking on!!).


    Use assertions to catch the NULL pointers that should never be null
    (i.e. indicating broken program logic) during debugging, then fix your
    code. Anything else is a bad hack.

    As for pointers which may be null, just check for nullity by comparing
    against the preprocessor macro NULL.
    , Dec 15, 2007
    #4
  5. Tony Jackson

    Flash Gordon Guest

    pete wrote, On 15/12/07 09:59:
    > Tony Jackson wrote:
    >> Hi
    >>
    >> I'm quite new to C programming - I have more of a Java background: maybe
    >> someone here can advise me.
    >>
    >> I'm nearly finishing a little program but it has some hard-to-find bugs
    >> that basically lead to a couple pointers sometimes being NULL at the
    >> wrong time. As it stands the program just bombs out when it tries to
    >> dereference the NULL, which obviously isn't good (especially when it
    >> happens with the customer looking on!!).


    Well, the program is not ready to put in front of a customer if you do
    not understand *why* the pointers are null.

    >> I don't think there's any serious problem to worry about,


    In that case I am glad that I am not your customer.

    >> and what I'd
    >> like to do is be able to ignore the dereference attempt and just carry
    >> on - probably the next time round the loop the pointer will be OK.


    Or, as you seem to not understand what is going on, something else that
    does not show up as easily might be wrong.

    >> In
    >> Java, I'd put a try block around the main loop, and if we catch an
    >> exception then just jump back to the start of the main loop.
    >> What's the
    >> corresponding thing in C?

    >
    > Put code in place to prevent
    > the deference attempt of the null pointer, instead.


    Or better yet actually find out why it is null and fix the real cause.
    --
    Flash Gordon
    Flash Gordon, Dec 15, 2007
    #5
  6. Tony Jackson

    santosh Guest

    Tony Jackson wrote:

    >> Put code in place to prevent
    >> the deference attempt of the null pointer, instead.

    >
    > Thanks for the reply. That would mean testing for NULL at every
    > pointer dereference which would be a lot of extra code - I was looking
    > for a catch-all solution. (Unfortunately I've already experienced
    > several different places where the program tries to dereference NULL,
    > and who knows how many others there are lurking in the background...)


    A short while back Martin Ambuhl posted an illustration of handling a
    SIGSEGV signal (which is what is likely to be delivered to your program
    on a null pointer deference) and continuing. Be aware though that the C
    standard explicitly says that the further behaviour of a program that
    handles SIGSEGV is undefined, so anything may happen. Your
    implementation may, however provide more guarantees.

    Your comments indicate that the code is broken, to say the least. I'm
    not sure about Java, but in C broken code generally leads to nasty
    surprises. Consider handling SIGSEGV only if a better option (like
    correcting the code in the first place) fails. Signal handling is
    subtle and difficult to get right in C.
    santosh, Dec 15, 2007
    #6
  7. Tony Jackson

    Chris Dollin Guest

    Tony Jackson wrote:

    > I'm quite new to C programming - I have more of a Java background: maybe
    > someone here can advise me.
    >
    > I'm nearly finishing a little program but it has some hard-to-find bugs
    > that basically lead to a couple pointers sometimes being NULL at the
    > wrong time. As it stands the program just bombs out when it tries to
    > dereference the NULL, which obviously isn't good (especially when it
    > happens with the customer looking on!!).
    >
    > I don't think there's any serious problem to worry about, and what I'd
    > like to do is be able to ignore the dereference attempt and just carry
    > on - probably the next time round the loop the pointer will be OK.


    (and then he said)

    > In Java, I'd put a try block around the main loop, and if we catch an
    > exception then just jump back to the start of the main loop.


    In Java, as in C, if our program dereferences a null, /it is an error/,
    and the program should be fixed. Yes, it's nice that you can catch the
    error in Java -- but you should /still/ work out /why/ some idiot code
    is dereferencing null, and sort it out.

    I've written a fair bit of Java, and blithely ignoring null pointer
    exceptions wasn't part of /any/ of it.

    Exception handling is for robustness, not wimping out. How on Earth
    do you know the program's in a safe state if it's been arbitrarily
    thrown out of by an NPE?

    --
    Non-Null Hedgehog
    Nit-picking is best done among friends.
    Chris Dollin, Dec 15, 2007
    #7
  8. Tony Jackson

    CBFalconer Guest

    Tony Jackson wrote:
    >
    > I'm quite new to C programming - I have more of a Java background: maybe
    > someone here can advise me.


    Yes. Try to write accurate code.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.


    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Dec 15, 2007
    #8
  9. Tony Jackson

    James Kuyper Guest

    Tony Jackson wrote:
    >> Put code in place to prevent
    >> the deference attempt of the null pointer, instead.

    >
    > Thanks for the reply. That would mean testing for NULL at every pointer
    > dereference which would be a lot of extra code - I was looking for a
    > catch-all solution. ...


    Properly designed code automatically ensures that pointers are not null
    when de-referenced; there's no need to insert large numbers of explicit
    tests for NULL except during debugging, when you're trying to figure out
    the way in which your code is improperly designed.

    Your code is obviously not properly designed in this regard, and you
    therefore DO need to debug it. I guarantee you that the kind of mistakes
    that result in attempts to dereference null pointers will not be minor,
    ignorable ones. Even if you could ignore such attempts, your program
    will go ahead and NOT do what you intended it to do. Fix the problems
    that cause such attempts to happen.

    > ... (Unfortunately I've already experienced several
    > different places where the program tries to dereference NULL, and who
    > knows how many others there are lurking in the background...)


    I would strongly recommend not using your program until you have found
    enough time to find and fix all of the bugs that
    James Kuyper, Dec 15, 2007
    #9
  10. "Chris Dollin" <> wrote in message
    > Tony Jackson wrote:
    >
    >> As it stands the program just bombs out when it tries to
    >> dereference the NULL, which obviously isn't good (especially when it
    >> happens with the customer looking on!!).

    >
    > Exception handling is for robustness, not wimping out. How on Earth
    > do you know the program's in a safe state if it's been arbitrarily
    > thrown out of by an NPE?
    >

    The customer isn't necessarily very sophisticated. He wants to see a program
    doing things on screen, so he's got confidence that the project is
    progressing to schedule. If the program bombs out with a segfault he
    interprets that as code in a very early stage of development. If it just
    produces a garbage answer but in a nice-looking dialogue box, he interprets
    that as a bit of a glitch that can be fixed.

    Whilst in the long run you have to get to the root of the problem, we don't
    all have the luxury of ignoring short term pressures.

    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Dec 15, 2007
    #10
  11. Tony Jackson

    Tor Rustad Guest

    Tony Jackson wrote:
    > Hi
    >
    > I'm quite new to C programming - I have more of a Java background: maybe
    > someone here can advise me.
    >
    > I'm nearly finishing a little program but it has some hard-to-find bugs
    > that basically lead to a couple pointers sometimes being NULL at the
    > wrong time. As it stands the program just bombs out when it tries to
    > dereference the NULL, which obviously isn't good (especially when it
    > happens with the customer looking on!!).


    Never had that problem in front of a customer! :) Dereferencing invalid
    pointers in the old days, was much more nasty, not only could we crash
    the OS, but even worse things could happen, like corrupting the file system.

    > I don't think there's any serious problem to worry about, and what I'd


    It should have been a major problem, don't count on your next costumer
    being equally ignorant.

    > like to do is be able to ignore the dereference attempt and just carry
    > on - probably the next time round the loop the pointer will be OK. In
    > Java, I'd put a try block around the main loop, and if we catch an
    > exception then just jump back to the start of the main loop. What's the
    > corresponding thing in C?


    The corresponding thing in C, would be to save environment via setjmp,
    install a signal handler for SIGSEGV and do a longjmp when such a signal
    occurs.

    This is *not* recommended practice in C, for a number of reasons. In C,
    you should fix the bugs, and tracking down NULL pointer dereferences, is
    easy.

    One simple method to catch your error, is via assert() in debug builds,
    just put in such checks on entry to *every* function:

    #include <stddef.h>
    #include <assert.h>

    void foo(char *pointer)
    {
    assert(pointer != NULL); /* check your assumptions */
    ...
    }

    int main(void)
    {
    char *pointer = NULL;

    ...
    foo(pointer);

    return 0;
    }

    for more complex memory errors, a tool like e.g. valgrind, is useful.

    --
    Tor < | tr i-za-h a-z>
    Tor Rustad, Dec 16, 2007
    #11
  12. Tony Jackson

    Ed Prochak Guest

    On Dec 15, 1:41 pm, "Malcolm McLean" <> wrote:
    []
    >
    > The customer isn't necessarily very sophisticated.


    Seems to me, neither is the programmer.



    A fine example of the perils of OO programming. Is JAVA the current
    source of evil that Dykstra once attributed to BASIC?
    Ed Prochak, Dec 16, 2007
    #12
  13. Tony Jackson

    Joe Wright Guest

    Tony Jackson wrote:
    > Hi
    >
    > I'm quite new to C programming - I have more of a Java background: maybe
    > someone here can advise me.
    >
    > I'm nearly finishing a little program but it has some hard-to-find bugs
    > that basically lead to a couple pointers sometimes being NULL at the
    > wrong time. As it stands the program just bombs out when it tries to
    > dereference the NULL, which obviously isn't good (especially when it
    > happens with the customer looking on!!).
    >
    > I don't think there's any serious problem to worry about, and what I'd
    > like to do is be able to ignore the dereference attempt and just carry
    > on - probably the next time round the loop the pointer will be OK. In
    > Java, I'd put a try block around the main loop, and if we catch an
    > exception then just jump back to the start of the main loop. What's the
    > corresponding thing in C?
    >
    > Thanks!
    >

    Java is not interesting here. "pointers sometimes being NULL at the
    wrong time." is not a bug, it's a serious design flaw.

    Don't show the customer any code you know to be faulty.

    There IS a serious problem to worry about: Your willingness to hide the
    problem and/or work through it is frightening. No programmer worth his
    salt will do that! If you are the Programmer, you cannot 'release' a
    program with known bugs. If you need help, ask for it.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Dec 16, 2007
    #13
  14. "Tor Rustad" <> wrote in message
    news:...
    > Tony Jackson wrote:
    >> Hi

    [...]
    >> like to do is be able to ignore the dereference attempt and just carry
    >> on - probably the next time round the loop the pointer will be OK. In
    >> Java, I'd put a try block around the main loop, and if we catch an
    >> exception then just jump back to the start of the main loop. What's the
    >> corresponding thing in C?

    >
    > The corresponding thing in C, would be to save environment via setjmp,
    > install a signal handler for SIGSEGV and do a longjmp when such a signal
    > occurs.


    longjmp isn't in the list of async-signal-safe functions:

    http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

    So you cannot call it from within a signal-handler. Use sigsetjmp/siglongjmp
    instead. Also, be careful to not call siglongjmp from a nested
    signal-handler as it results in undefined behavior:

    http://opengroup.org/onlinepubs/007908799/xsh/siglongjmp.html
    Chris Thomasson, Dec 16, 2007
    #14
  15. Tony Jackson

    Tor Rustad Guest

    Chris Thomasson wrote:
    > "Tor Rustad" <> wrote in message
    > news:...
    >> Tony Jackson wrote:
    >>> Hi

    > [...]
    >>> like to do is be able to ignore the dereference attempt and just carry
    >>> on - probably the next time round the loop the pointer will be OK. In
    >>> Java, I'd put a try block around the main loop, and if we catch an
    >>> exception then just jump back to the start of the main loop. What's the
    >>> corresponding thing in C?

    >>
    >> The corresponding thing in C, would be to save environment via setjmp,
    >> install a signal handler for SIGSEGV and do a longjmp when such a
    >> signal occurs.

    >
    > longjmp isn't in the list of async-signal-safe functions:


    One of the reasons I didn't recommend OP doing this, was that
    from the point of ISO C, calling longjmp from a signal handler invokes
    UB. However, but so does dereferencing NULL pointer. If OP want a
    well-defined C program, the NULL dereference has to be removed.

    IIRC, Stevens did use longjmp from a signal handler in APUE, so it
    appears that this was at one point allowed in POSIX environments.

    > So you cannot call it from within a signal-handler. Use
    > sigsetjmp/siglongjmp instead. Also, be careful to not call siglongjmp
    > from a nested signal-handler as it results in undefined behavior:


    Very little can be done in C99 signal handlers, calling siglongjmp() is
    not on that list, the sigsetjmp/siglongjmp is POSIX functions (off-topic
    here, but on-topic in c.u.programmer).

    --
    Tor < | tr i-za-h a-z>
    Tor Rustad, Dec 17, 2007
    #15
  16. Tony Jackson

    Randy Howard Guest

    On Sat, 15 Dec 2007 03:52:53 -0600, Tony Jackson wrote
    (in article <>):

    > Hi
    >
    > I'm quite new to C programming - I have more of a Java background: maybe
    > someone here can advise me.
    >
    > I'm nearly finishing a little program but it has some hard-to-find bugs
    > that basically lead to a couple pointers sometimes being NULL at the
    > wrong time. As it stands the program just bombs out when it tries to
    > dereference the NULL, which obviously isn't good (especially when it
    > happens with the customer looking on!!).


    Rule #1: Don't show the customer the program before it is finished.

    > I don't think there's any serious problem to worry about,



    This is almost certain to be a very poor belief to hold,

    > and what I'd
    > like to do is be able to ignore the dereference attempt and just carry
    > on


    And this is probably not the right approach to handle it either.

    - probably the next time round the loop the pointer will be OK.

    Because of divine intervention?

    > In
    > Java, I'd put a try block around the main loop, and if we catch an
    > exception then just jump back to the start of the main loop. What's the
    > corresponding thing in C?


    Detect the error, and take appropriate action when it occurs.


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
    Randy Howard, Dec 28, 2007
    #16
  17. Tony Jackson

    Eric Guest

    Randy Howard wrote:

    > On Sat, 15 Dec 2007 03:52:53 -0600, Tony Jackson wrote
    > (in article <>):
    >
    >> Hi
    >>
    >> I'm quite new to C programming - I have more of a Java background: maybe
    >> someone here can advise me.
    >>
    >> I'm nearly finishing a little program but it has some hard-to-find bugs
    >> that basically lead to a couple pointers sometimes being NULL at the
    >> wrong time. As it stands the program just bombs out when it tries to
    >> dereference the NULL, which obviously isn't good (especially when it
    >> happens with the customer looking on!!).

    >
    > Rule #1: Don't show the customer the program before it is finished.
    >
    >> I don't think there's any serious problem to worry about,

    >
    >
    > This is almost certain to be a very poor belief to hold,
    >
    >> and what I'd
    >> like to do is be able to ignore the dereference attempt and just carry
    >> on

    >
    > And this is probably not the right approach to handle it either.
    >
    > - probably the next time round the loop the pointer will be OK.
    >
    > Because of divine intervention?
    >
    >> In
    >> Java, I'd put a try block around the main loop, and if we catch an
    >> exception then just jump back to the start of the main loop. What's the
    >> corresponding thing in C?

    >
    > Detect the error, and take appropriate action when it occurs.
    >
    >

    Whats really scary is that guys like this might be writing aircraft control
    software. Got a NULL pointer? ah dont worry, just run it 4 or 5 times it
    will go. Array too small? no problemo, there's always extra space off the
    end we can use. God help us! Its no wonder that most things today that have
    any kind of built in control program are pure crap (e.g. remote controls,
    home routers, DVR's etc etc).
    Eric, Dec 28, 2007
    #17
  18. Tony Jackson

    Randy Howard Guest

    On Fri, 28 Dec 2007 11:24:32 -0600, Eric wrote
    (in article <>):

    > Randy Howard wrote:
    >
    >> On Sat, 15 Dec 2007 03:52:53 -0600, Tony Jackson wrote
    >> (in article <>):
    >>
    >>> Hi
    >>>
    >>> I'm quite new to C programming - I have more of a Java background: maybe
    >>> someone here can advise me.
    >>>
    >>> I'm nearly finishing a little program but it has some hard-to-find bugs
    >>> that basically lead to a couple pointers sometimes being NULL at the
    >>> wrong time. As it stands the program just bombs out when it tries to
    >>> dereference the NULL, which obviously isn't good (especially when it
    >>> happens with the customer looking on!!).

    >>
    >> Rule #1: Don't show the customer the program before it is finished.
    >>
    >>> I don't think there's any serious problem to worry about,

    >>
    >>
    >> This is almost certain to be a very poor belief to hold,
    >>
    >>> and what I'd
    >>> like to do is be able to ignore the dereference attempt and just carry
    >>> on

    >>
    >> And this is probably not the right approach to handle it either.
    >>
    >> - probably the next time round the loop the pointer will be OK.
    >>
    >> Because of divine intervention?
    >>
    >>> In
    >>> Java, I'd put a try block around the main loop, and if we catch an
    >>> exception then just jump back to the start of the main loop. What's the
    >>> corresponding thing in C?

    >>
    >> Detect the error, and take appropriate action when it occurs.
    >>
    >>

    > Whats really scary is that guys like this might be writing aircraft control
    > software. Got a NULL pointer? ah dont worry, just run it 4 or 5 times it
    > will go.



    Or a nuclear power plant, or airbag deployment code in a car, or ....
    the list is quite long these days.

    > Array too small? no problemo, there's always extra space off the
    > end we can use.


    Yes, and don't forget, malloc never fails. :)

    > God help us! Its no wonder that most things today that have
    > any kind of built in control program are pure crap (e.g. remote controls,
    > home routers, DVR's etc etc).


    Yes, when everything is built by the lowest bidder, and nobody will buy
    anything that's not on the top of the list, when sorted by price low to
    high, then you get mostly crap.


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
    Randy Howard, Dec 29, 2007
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Denis Palmeiro

    NULL Pointer Dereference

    Denis Palmeiro, Jul 8, 2003, in forum: C Programming
    Replies:
    10
    Views:
    651
    Shill
    Jul 16, 2003
  2. Replies:
    6
    Views:
    431
    Alf P. Steinbach
    Oct 3, 2007
  3. aneuryzma
    Replies:
    3
    Views:
    690
    Jim Langston
    Jun 16, 2008
  4. Armen Tsirunyan
    Replies:
    18
    Views:
    510
    James Kanze
    Oct 5, 2010
  5. Christopher
    Replies:
    4
    Views:
    425
    Ruben Safir
    Jul 9, 2011
Loading...

Share This Page