Re: Where the code trouble is?

Bryan Donlan wrote: 
Walter Roberson wrote:

In article <430f8b55@xxxxxxxxxxxxx>, Bart C <bc@xxxxxxxxxx> wrote:

"Richard Bos" <rlb@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:430ec081.236466745@xxxxxxxxxxxxxxxxx


Writing through a null pointer is no more defined than writing through a
wild pointer.


Maybe, but an error is more or less guaranteed with a null pointer and
makes it easy to check for.


I know of at least two architectures in which NULL is all-zero-bits
but in which writing at (or near that location, such as  a[3] when
a is NULL) would NOT result in a trap, because the architectures happen
to have memory at that location.


The vast majority of machines in use have NULL as a trap location. Richard's
development system likely does so as well. Although *NULL might well not
trap, it's in general more likely to, which can help with debugging.

This will not catch all such errors of course, but it doesn't hurt anything,
except for causing a tiny (probably imperceptible) performance hit, and may
help with debugging.


Agreed.

I would also say that even on systems where writing to *NULL does not trap, it is still likely (but not guaranteed) to give reproduceable results which can be debugged.

For similar reasons on embedded systems I have changed the startup code so that all RAM was initialised to all bits 0. I did not check on the system whether NULL was all bits 0 or whether float or double 0 where all bits 0, but it did meen the software was more predictable and easier to debug when accessing uninitialised data. On another system they initialised all RAM to 0x55 for the similar reason (I used all bits 0 because static variables without an initialiser where *not* set to 0).

IMHO the first stage in trying to debug a problem is always to reproduce it, since if you can't reliably reproduce it you will never know if you have fixed what caused the original bug report or something else that you think might have caused it but did not.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
.

Relevant Pages

  • Re: Where the code trouble is?
    ... The vast majority of machines in use have NULL as a trap location. ... trap, it's in general more likely to, which can help with debugging. ... I would also say that even on systems where writing to *NULL does not trap, it is still likely to give reproduceable results which can be debugged. ... IMHO the first stage in trying to debug a problem is always to reproduce it, since if you can't reliably reproduce it you will never know if you have fixed what caused the original bug report or something else that you think might have caused it but did not. ...
    (comp.lang.c)
  • Re: Where the code trouble is?
    ... >>> Writing through a null pointer is no more defined than writing through a ... >>> wild pointer. ... The vast majority of machines in use have NULL as a trap location. ... trap, it's in general more likely to, which can help with debugging. ...
    (comp.lang.c)
  • Re: Want function or class that uses reflection to iterate over properties in custom object
    ... use a "real" IDE with debugging support. ... > Why don't you use the debugger instead of writing debug code. ... I build and extend a lot of custom objects, ... I've learned that you can do this using reflection. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: segmentation fault - code attached
    ... It is used in VLSI for debugging and waveform dump in ... I was writing a library for the format. ... > `struct Var'. ... Artie Gold -- Austin, Texas ...
    (comp.lang.c)
  • Re: ANSI C compliance
    ... > Writing a significant chunk of embedded code. ... > workstation and debugging it there because there were far better tools ... I used some stubs for platform specific functionality. ... C++ Faq: http://www.parashift.com/c++-faq-lite ...
    (comp.lang.c)