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...@xxxxxxxxx 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...@xxxxxxxxxxxxxxxxxxx> wrote:
santosh wrote:
Clever Monkey wrote:
Richard Tobin wrote:
In article <1169768146.763494.270...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
tedu <t...@xxxxxxxxxxxxx> wrote:

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.

.

Relevant Pages

  • Re: checking if pointer is NULL allowed?
    ... If it has been freed and causes the debug to crash, ... generally not interested in the pointer once it has been freedCare to show how you would implement this? ... There are routines that allocate a chunk of memory to store a number ...
    (comp.lang.c)
  • Re: checking if pointer is NULL allowed?
    ... macro used in debugging routines that can take a pointer and return the ... If it has been freed and causes the debug to crash, ... There are routines that allocate a chunk of memory to store a number ...
    (comp.lang.c)
  • Re: checking if pointer is NULL allowed?
    ... macro used in debugging routines that can take a pointer and return the ... There are routines that allocate a chunk of memory to store a number of structs and lists of structs, and there are routines that these things up when we are done. ... None of our debug lines would use such a pointer after it had been freed. ...
    (comp.lang.c)
  • Re: Release version crashes - again
    ... DWORD *pointer = NULL; ... are not usually equal in retail, but they usually are in debug. ... but my code is crashing in the CONSTRUCTOR area (long ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Dealing with HANDLEs
    ... On every new process event this program creates a new Process object and ... pointer and assigns the pointer from the to it. ... This worked in debug. ... Strange, I thought if I pass a pointer, it's like by ref, I can change its ...
    (microsoft.public.win32.programmer.kernel)