I've seen some people do
if ( 0 == foo )
{
...
}
in C to try to avoid this particular "dumb error."
(Just try compiling using "if ( 0 = foo )" )
Hmmm. Perhaps Pascal's ":=" thingie ain't so
stupid after all...
D
* On Fri, Feb 09, 2001 at 09:57:52PM -0700, Alan Dayley wrote:
> At 04:00 PM 2/9/01 +0000, you wrote:
> >Ive found that if you understand the sourcecode, often *adding* lines
> >that output information to a file somewhere as the program runs beats
> >the snot out of any "after the fact" debugger. Doing it that way makes
> >it possible to spot verify any area of a program ...
>
> In embedded systems debug outputs can change the behavior of the system,
> especially when multi-tasking. But then, a debugger can change the
> behavior of the system too. Embedded can be so fun!
>
> Serious debugging, looking at memory, viewing structures, stepping through
> the code can save LOADS of time. It is one of my cardinal rules: Always
> step through new code at least the first time you run it. I can save loads
> of time, especially on the dumb errors like:
>
> if (foo = 0)
> {
> ...
> }
>
> Sometimes outputs are all you can do, especially if you don't have a good
> debugger or emulator.
>
> >Whats your opinion on this approach to debugging? (obviously you dont
> >want those code snippets showing up in a production release, however!)
>
> Make sure you bracket the the debug code with "#ifdef DEBUG" or something
> like that (whatever your language allows) and have a debug build and
> release build in your makefile.
>
> This is basic stuff. I like to share, though.
>
> Alan
(text/plain)