468,491 Members | 2,010 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,491 developers. It's quick & easy.

Avoiding dereference of NULL pointer

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!

Dec 15 '07 #1
17 5900
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
Dec 15 '07 #2
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...)

Dec 15 '07 #3
On Dec 15, 10:52 am, Tony Jackson <tj76...@DELETETHIS.gmail.com>
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 '07 #4
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.

Dec 15 '07 #5
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
Dec 15 '07 #6
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.

Dec 15 '07 #7
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
Dec 15 '07 #8
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

Dec 15 '07 #9

"Chris Dollin" <eh@electrichedgehog.netwrote 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

Dec 15 '07 #10
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 <bw****@wvtqvm.vw | tr i-za-h a-z>
Dec 16 '07 #11
On Dec 15, 1:41 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
[]
>
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?
Dec 16 '07 #12
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 ---
Dec 16 '07 #13
"Tor Rustad" <to********@hotmail.comwrote in message
news:yI*********************@telenor.com...
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/...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/0079...iglongjmp.html

Dec 16 '07 #14
Chris Thomasson wrote:
"Tor Rustad" <to********@hotmail.comwrote in message
news:yI*********************@telenor.com...
>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 <bw****@wvtqvm.vw | tr i-za-h a-z>
Dec 17 '07 #15
On Sat, 15 Dec 2007 03:52:53 -0600, Tony Jackson wrote
(in article <sl*******************@nospam.invalid>):
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

Dec 28 '07 #16
Randy Howard wrote:
On Sat, 15 Dec 2007 03:52:53 -0600, Tony Jackson wrote
(in article <sl*******************@nospam.invalid>):
>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).

Dec 28 '07 #17
On Fri, 28 Dec 2007 11:24:32 -0600, Eric wrote
(in article <LO******************************@comcast.com>):
Randy Howard wrote:
>On Sat, 15 Dec 2007 03:52:53 -0600, Tony Jackson wrote
(in article <sl*******************@nospam.invalid>):
>>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

Dec 29 '07 #18

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Denis Palmeiro | last post: by
6 posts views Thread by TuxC0d3 | last post: by
30 posts views Thread by somenath | last post: by
2 posts views Thread by andrey.vul | last post: by
26 posts views Thread by =?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?= | last post: by
8 posts views Thread by Rafael Anschau | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by theflame83 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.