checking if pointer is NULL allowed?

[Clever Monkey]

Re: checking if pointer is NULL allowed?

Richard Tobin wrote:

In article <1169768146.763 494.270880@a75g 2000cwd.googleg roups.com>,
tedu <tu@zeitbombe.o rgwrote:
>

>>>It is common practice in many shops I've worked at to have a function or
>>>macro used in debugging routines that can take a pointer and return the
>>>pointer or "null", depending on if the pointer is valid to dereference
>>>or not.

>

>>Maybe, but that's not possible in standard C.

>

>why not?

>
You can tell whether it's null (which I suspect is what was meant) but
you can't check that it's "valid to dereference" - it might be a
free()ed pointer for example.
>

We check it for null, which is a valid enough check for a debug/logging
routine. If it has been freed and causes the debug to crash, then we
can consider this a "free" assert and can fix it, because we are
generally not interested in the pointer once it has been freed.

That is, in the context of a debug statement, a "valid pointer" is one
that is either null or can be dereferenced legally to pass to printf.

[Clever Monkey]

Re: checking if pointer is NULL allowed?

Ben Pfaff wrote:

Clever Monkey <clvrmnky.inval id@hotmail.com. invalidwrites:
>

>It is common practice in many shops I've worked at to have a function
>or macro used in debugging routines that can take a pointer and return
>the pointer or "null", depending on if the pointer is valid to
>dereference or not.

>
What kind of code do you work on?

The code I am most familiar with where we have such debug routines is a
chunk of legacy code that does a fair amount of string manipulation on
items that are passed around in "instance" pointers that refer to files
and describe relationships to other files and pointers.

When I got here the debug routines were already in place. Basically we
have a debug module that we link in that has a run-time component. We
check for a few environment variables on startup, and based on that
enable 1-4 levels of debug() statements. If the variables are not set
the debug statements are turned into no-ops.

The debugging routines are implemented as varargs (I recall), so for
strings we know might be null we pass them through a "nulString( )"
helper function that returns the pointer unmaligned, or the equivalent
replacement string that simply says "null" (or something).

For other issues, like pointers that might be freed before logging them,
this would be a bug in the code and a failure in the logger may as well
be caught ASAP.

It isn't perfect, and may in fact break some conventions or rules by
today's standards, but it was put in place literally decades ago.
Changing it now would introduce significant risk without giving us
something obvious in return. It is unlikely we are going to port this
library to any more platforms. It already runs nicely on a gaggle of
Unices and a long history of Windows stretching back to Win16. (Though
I'm sure it would break nicely on Win16 now).

Alas, the sun is sinking on this code as more and more is subsumed by
newer code written in Java.

[Chris Dollin]

Re: checking if pointer is NULL allowed?

Clever Monkey wrote:

Ben Pfaff wrote:

>Clever Monkey <clvrmnky.inval id@hotmail.com. invalidwrites:
>>

>>It is common practice in many shops I've worked at to have a function
>>or macro used in debugging routines that can take a pointer and return
>>the pointer or "null", depending on if the pointer is valid to
>>dereference or not.

>>
>What kind of code do you work on?

The debugging routines are implemented as varargs (I recall), so for
strings we know might be null we pass them through a "nulString( )"
helper function that returns the pointer unmaligned, or the equivalent
replacement string that simply says "null" (or something).

Ahhh. So what you mean is, a function that says:

return arg == null ? "null" : arg;

Yes, that's fine in standard C, but that's not what I read "valid to
dereference" as meaning.

--
Chris "electric hedgehog" Dollin
Meaning precedes definition.

[santosh]

Re: checking if pointer is NULL allowed?

Clever Monkey wrote:

Richard Tobin wrote:

In article <1169768146.763 494.270880@a75g 2000cwd.googleg roups.com>,
tedu <tu@zeitbombe.o rgwrote:

>>It is common practice in many shops I've worked at to have a function or
>>macro used in debugging routines that can take a pointer and return the
>>pointer or "null", depending on if the pointer is valid to dereference
>>or not.

>Maybe, but that's not possible in standard C.

why not?

You can tell whether it's null (which I suspect is what was meant) but
you can't check that it's "valid to dereference" - it might be a
free()ed pointer for example.

We check it for null, which is a valid enough check for a debug/logging
routine. If it has been freed and causes the debug to crash, then we
can consider this a "free" assert and can fix it, because we are
generally not interested in the pointer once it has been freed.

So what is done with the pointers after they've been free()'ed?

That is, in the context of a debug statement, a "valid pointer" is one
that is either null or can be dereferenced legally to pass to printf.

So the check doesn't really verify that a non-null pointer can be
validly deferenced. That much can be done with standard C, and IMHO,
it's not very useful.

[Chris Dollin]

Re: checking if pointer is NULL allowed?

santosh wrote:

So the check doesn't really verify that a non-null pointer can be
validly deferenced. That much can be done with standard C, and IMHO,
it's not very useful.

It's useful for debug prints, which is what Clever Monkey said they
were used in. Myself, I'd likely have a cut-down version of (va)printf,
with %s doing an explicit check for null: then I don't have to remember
to call the replace-null-with-"null" function in calls.

--
Chris "electric hedgehog" Dollin
"Who are you? What do you want?" /Babylon 5/

[Chris Torek]

Re: checking if pointer is NULL allowed?

>On Fri, 26 Jan 2007 08:25:36 +0000, Chris Dollin <chris.dollin@h p.com>

>wrote:

>>(A /specific implementation/ might offer such a function, although
>I can't see it being both reliable and cheap.)

In article <8bijr25mcvgkst 0lkpo5g4l7m4ear uhts6@4ax.com>
jaysome <jaysome@hotmai l.comwrote:

>It depends on your definitions of "reliable" and "cheap".

Indeed. Particularly "reliable". :-)

[snippage]

num_bad += IsBadReadPtr((v oid*)ii, 1) != 0;//lint !e514

Before using IsBad{Read,Writ e}Ptr on Windows machines, see
<http://blogs.msdn.com/larryosterman/archive/2004/05/18/134471.aspx>.
The way IsBadReadPtr affects stack guard pages is particularly
tricky.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Clever Monkey]

Re: checking if pointer is NULL allowed?

Chris Dollin wrote:

santosh wrote:
>

>So the check doesn't really verify that a non-null pointer can be
>validly deferenced. That much can be done with standard C, and IMHO,
>it's not very useful.

>
It's useful for debug prints, which is what Clever Monkey said they
were used in. Myself, I'd likely have a cut-down version of (va)printf,
with %s doing an explicit check for null: then I don't have to remember
to call the replace-null-with-"null" function in calls.
>

We've thought about replacing this some time ago, but this is seriously
legacy code. The debug stuff is never on anymore anyway, since it is
called via JNI now.

[Clever Monkey]

Re: checking if pointer is NULL allowed?

santosh wrote:

Clever Monkey wrote:

>Richard Tobin wrote:

>>In article <1169768146.763 494.270880@a75g 2000cwd.googleg roups.com>,
>>tedu <tu@zeitbombe.o rgwrote:
>>>
>>>>>It is common practice in many shops I've worked at to have a function or
>>>>>macro used in debugging routines that can take a pointer and return the
>>>>>pointer or "null", depending on if the pointer is valid to dereference
>>>>>or not.
>>>>Maybe, but that's not possible in standard C.
>>>why not?
>>You can tell whether it's null (which I suspect is what was meant) but
>>you can't check that it's "valid to dereference" - it might be a
>>free()ed pointer for example.
>>>

>We check it for null, which is a valid enough check for a debug/logging
>routine. If it has been freed and causes the debug to crash, then we
>can consider this a "free" assert and can fix it, because we are
>generally not interested in the pointer once it has been freed.

>
So what is done with the pointers after they've been free()'ed?
>

Er, nothing? I'm not sure what you mean. Whether something has been
freed are it has not. Generally, during the lifetime of this library,
things are freed only in very specific places. Everywhere else they
should either be null (are not filled out in this context, or are
otherwise valid and can be used by the callee) or are valid (i.e., point
at something meaningful) in some manner.

That is, we do not malloc stuff a willy-nilly, freeing things whenever.
There are routines that allocate a chunk of memory to store a number
of structs and lists of structs (handling any allocation errors there),
and there are routines that these things up when we are done. There are
a few places where we allocate space for something, but it is generally
allocated and freed within the same function. None of our debug lines
would use such a pointer after it had been freed.

Violating this in the routines that have debug statements, when
debugging is enabled, will cause some sort of undefined behaviour. If
we catch it (whether or not the debug raises the problem) we would fix it.

[Alef.Veld@gmail.com]

Re: checking if pointer is NULL allowed?

Ok, so maybe i'm way off base here, but

a) why is a variable not initialized to say, NULL when it is declared
but the programmer forgot to assign some useful value to it? This also
would implicate to me that when free() frees a ptr, it assigns it null.
What other value could it possible have ? At least for pointers, it's
bad for them to point at nothingness, so why not always set them to
NULL ? I don't think this would impair the language in anyway or does
it?

I understand that it's the responsibility of the programmer et al, but
i'm pretty sure that by setting it to null _alot_ of problems would be
fixed.

Then again, maybe not :-)

On Jan 26, 9:13 pm, Clever Monkey
<clvrmnky.inva. ..@hotmail.com. invalidwrote:

santosh wrote:

Clever Monkey wrote:

Richard Tobin wrote:
>In article <1169768146.763 494.270...@a75g 2000cwd.googleg roups.com>,
>tedu <t...@zeitbombe .orgwrote:

>

>>>>It is common practice in many shops I've worked at to have a function or
>>>>macro used in debugging routines that can take a pointer and return the
>>>>pointer or "null", depending on if the pointer is valid to dereference
>>>>or not.
>>>Maybe, but that's not possible in standard C.
>>why not?
>You can tell whether it's null (which I suspect is what was meant) but
>you can't check that it's "valid to dereference" - it might be a
>free()ed pointer for example.

>

We check it for null, which is a valid enough check for a debug/logging
routine. If it has been freed and causes the debug to crash, then we
can consider this a "free" assert and can fix it, because we are
generally not interested in the pointer once it has been freed.

>

So what is done with the pointers after they've been free()'ed?Er, nothing? I'm not sure what you mean. Whether something has been

freed are it has not. Generally, during the lifetime of this library,
things are freed only in very specific places. Everywhere else they
should either be null (are not filled out in this context, or are
otherwise valid and can be used by the callee) or are valid (i.e., point
at something meaningful) in some manner.
>
That is, we do not malloc stuff a willy-nilly, freeing things whenever.
There are routines that allocate a chunk of memory to store a number
of structs and lists of structs (handling any allocation errors there),
and there are routines that these things up when we are done. There are
a few places where we allocate space for something, but it is generally
allocated and freed within the same function. None of our debug lines
would use such a pointer after it had been freed.
>
Violating this in the routines that have debug statements, when
debugging is enabled, will cause some sort of undefined behaviour. If
we catch it (whether or not the debug raises the problem) we would fix it.

[Alef.Veld@gmail.com]

Re: checking if pointer is NULL allowed?

Err sorry i missed this:

>We check it for null, which is a valid enough check for a debug/logging
>routine. If it has been freed and causes the debug to crash, then we
>can consider this a "free" assert and can fix it, because we are
>generally not interested in the pointer once it has been freed

Care to show how you would implement this ?

On Jan 27, 11:07 am, Alef.V...@gmail .com wrote:

Ok, so maybe i'm way off base here, but
>
a) why is a variable not initialized to say, NULL when it is declared
but the programmer forgot to assign some useful value to it? This also
would implicate to me that when free() frees a ptr, it assigns it null.
What other value could it possible have ? At least for pointers, it's
bad for them to point at nothingness, so why not always set them to
NULL ? I don't think this would impair the language in anyway or does
it?
>
I understand that it's the responsibility of the programmer et al, but
i'm pretty sure that by setting it to null _alot_ of problems would be
fixed.
>
Then again, maybe not :-)
>
On Jan 26, 9:13 pm, Clever Monkey
>
<clvrmnky.inva. ..@hotmail.com. invalidwrote:

santosh wrote:

Clever Monkey wrote:
>Richard Tobin wrote:
>>In article <1169768146.763 494.270...@a75g 2000cwd.googleg roups.com>,
>>tedu <t...@zeitbombe .orgwrote:

>

>>>>>It is common practice in many shops I've worked at to have a function or
>>>>>macro used in debugging routines that can take a pointer and return the
>>>>>pointer or "null", depending on if the pointer is valid to dereference
>>>>>or not.
>>>>Maybe, but that's not possible in standard C.
>>>why not?
>>You can tell whether it's null (which I suspect is what was meant) but
>>you can't check that it's "valid to dereference" - it might be a
>>free()ed pointer for example.

>

>We check it for null, which is a valid enough check for a debug/logging
>routine. If it has been freed and causes the debug to crash, then we
>can consider this a "free" assert and can fix it, because we are
>generally not interested in the pointer once it has been freed.

>

So what is done with the pointers after they've been free()'ed?Er, nothing? I'm not sure what you mean. Whether something has been

freed are it has not. Generally, during the lifetime of this library,
things are freed only in very specific places. Everywhere else they
should either be null (are not filled out in this context, or are
otherwise valid and can be used by the callee) or are valid (i.e., point
at something meaningful) in some manner.

>

That is, we do not malloc stuff a willy-nilly, freeing things whenever.
There are routines that allocate a chunk of memory to store a number
of structs and lists of structs (handling any allocation errors there),
and there are routines that these things up when we are done. There are
a few places where we allocate space for something, but it is generally
allocated and freed within the same function. None of our debug lines
would use such a pointer after it had been freed.

>

Violating this in the routines that have debug statements, when
debugging is enabled, will cause some sort of undefined behaviour. If
we catch it (whether or not the debug raises the problem) we would fix it.

[Alef.Veld@gmail.com]

Re: checking if pointer is NULL allowed?



On Jan 27, 11:09 am, Alef.V...@gmail .com wrote:

Err sorry i missed this:
>

We check it for null, which is a valid enough check for a debug/logging
routine. If it has been freed and causes the debug to crash, then we
can consider this a "free" assert and can fix it, because we are
generally not interested in the pointer once it has been freedCare to show how you would implement this ?

>
On Jan 27, 11:07 am, Alef.V...@gmail .com wrote:
>

Ok, so maybe i'm way off base here, but

>

a) why is a variable not initialized to say, NULL when it is declared
but the programmer forgot to assign some useful value to it? This also
would implicate to me that when free() frees a ptr, it assigns it null.
What other value could it possible have ? At least for pointers, it's
bad for them to point at nothingness, so why not always set them to
NULL ? I don't think this would impair the language in anyway or does
it?

>

I understand that it's the responsibility of the programmer et al, but
i'm pretty sure that by setting it to null _alot_ of problems would be
fixed.

>

Then again, maybe not :-)

>

On Jan 26, 9:13 pm, Clever Monkey

>

<clvrmnky.inva. ..@hotmail.com. invalidwrote:

santosh wrote:
Clever Monkey wrote:
Richard Tobin wrote:
>In article <1169768146.763 494.270...@a75g 2000cwd.googleg roups.com>,
>tedu <t...@zeitbombe .orgwrote:

>

>>>>It is common practice in many shops I've worked at to have a function or
>>>>macro used in debugging routines that can take a pointer and return the
>>>>pointer or "null", depending on if the pointer is valid to dereference
>>>>or not.
>>>Maybe, but that's not possible in standard C.
>>why not?
>You can tell whether it's null (which I suspect is what was meant) but
>you can't check that it's "valid to dereference" - it might be a
>free()ed pointer for example.

>

We check it for null, which is a valid enough check for a debug/logging
routine. If it has been freed and causes the debug to crash, then we
can consider this a "free" assert and can fix it, because we are
generally not interested in the pointer once it has been freed.

>

So what is done with the pointers after they've been free()'ed?Er, nothing? I'm not sure what you mean. Whether something has been
freed are it has not. Generally, during the lifetime of this library,
things are freed only in very specific places. Everywhere else they
should either be null (are not filled out in this context, or are
otherwise valid and can be used by the callee) or are valid (i.e., point
at something meaningful) in some manner.

>

That is, we do not malloc stuff a willy-nilly, freeing things whenever.
There are routines that allocate a chunk of memory to store a number
of structs and lists of structs (handling any allocation errors there),
and there are routines that these things up when we are done. There are
a few places where we allocate space for something, but it is generally
allocated and freed within the same function. None of our debug lines
would use such a pointer after it had been freed.

>

Violating this in the routines that have debug statements, when
debugging is enabled, will cause some sort of undefined behaviour. If
we catch it (whether or not the debug raises the problem) we would fix it.

Excusez-moi for the top-post. My bad.

[santosh]

Re: checking if pointer is NULL allowed?

Alef.Veld@gmail .com wrote:

Please don't top-post.

On Jan 26, 9:13 pm, Clever Monkey

santosh wrote:

Clever Monkey wrote:

<snip>

>We check it for null, which is a valid enough check for a debug/logging
>routine. If it has been freed and causes the debug to crash, then we
>can consider this a "free" assert and can fix it, because we are
>generally not interested in the pointer once it has been freed.

So what is done with the pointers after they've been free()'ed?Er, nothing?

I'm not sure what you mean. Whether something has been
freed are it has not. Generally, during the lifetime of this library,
things are freed only in very specific places. Everywhere else they
should either be null (are not filled out in this context, or are
otherwise valid and can be used by the callee) or are valid (i.e., point
at something meaningful) in some manner.

<snip>

Ok, so maybe i'm way off base here, but
>
a) why is a variable not initialized to say, NULL when it is declared
but the programmer forgot to assign some useful value to it? This also
would implicate to me that when free() frees a ptr, it assigns it null.

No it doesn't. The pointer has an indeterminate value after it has been
free()'ed. You'll have to explicitly set it to null if you want to.

What other value could it possible have ? At least for pointers, it's
bad for them to point at nothingness, so why not always set them to
NULL ? I don't think this would impair the language in anyway or does
it?

Yes, this is a good practise, but as in many other things, C doesn't
force you to do it, or do it behind your back.

I understand that it's the responsibility of the programmer et al, but
i'm pretty sure that by setting it to null _alot_ of problems would be
fixed.

As the "variable initialisation" thread is discussing, pointers which
hold valid, deferencible values or are null would behave more
predictably than uninitialised pointers. Again C doesn't do this
automatically.

[CBFalconer]

Re: checking if pointer is NULL allowed?

Alef.Veld@gmail .com wrote:

>
Ok, so maybe i'm way off base here, but
>
a) why is a variable not initialized to say, NULL when it is
declared but the programmer forgot to assign some useful value to
it? This also would implicate to me that when free() frees a ptr,
it assigns it null. What other value could it possible have ? At
least for pointers, it's bad for them to point at nothingness, so
why not always set them to NULL ? I don't think this would impair
the language in anyway or does it?
>
I understand that it's the responsibility of the programmer et al,
but i'm pretty sure that by setting it to null _alot_ of problems
would be fixed.

In part, because such initialization of local storage involves
extra code. In the typical implementation automatic storage is
stack based, and that memory contains whatever was left in it by
previous use. The fact that the extra code is hidden from the
programmer in initialization statements does not affect it. When
you are shoehorning things into a miniscule embedded system it can
make a major difference.

As far as setting pointer to NULL (not null) after free, it can't
be done by the free routine, because parameters are passed by value
in C. free doesn't have access to the pointer.

Please don't top-post. Your answer belongs after, or intermixed
with, the material to which you reply, after snipping irrelevant
material. See the following links:

--
Some informative links:
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html >
<http://www.netmeister. org/news/learn2quote.htm l>
<http://cfaj.freeshell. org/google/ (taming google)
<http://members.fortune city.com/nnqweb/ (newusers)

[Kenny McCormack]

Re: checking if pointer is NULL allowed? - GAL

In article <51q6opF1loio4U 1@mid.individua l.net>,
Default User <defaultuserbr@ yahoo.comwrote:

>Alef.Veld@gmai l.com wrote:
>

>that's what i suspected and wanted to hear, thanks :-)

>
>Please don't top-post. Your replies belong following or interspersed
>with properly trimmed quotes. See the majority of other posts in the
>newsgroup, or:
><http://www.caliburn.nl/topposting.html >

Get a life!

[Richard Tobin]

Re: checking if pointer is NULL allowed?

In article <1169892441.332 187.205360@s48g 2000cws.googleg roups.com>,
<Alef.Veld@gmai l.comwrote:

>a) why is a variable not initialized to say, NULL when it is declared
>but the programmer forgot to assign some useful value to it?

In fact, this would be quite reasonable if we were designing C now.
The same analysis that allows most optimising compilers to report
uninitialised variables would allow them to omit the the default
initialisation in almost all cases where it was unnecessary.

>This also
>would implicate to me that when free() frees a ptr, it assigns it null.

That's not practical in a language like C. free() does not have
access to the variable whose value is passed to it, even assuming that
it *is* a variable rather than an expression. And of course there may
be many other variables pointing to the same free()ed memory.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.