Hello Francois!

On 07.02.97 you wrote:

 FT> Hello All!

 FT> I have mentionned here before that my main debugging tool is writeln()
 FT> or printf/assert.

I must confess I would not like to miss an interactive debugger during
development... in my experience, you always forget to printf() the variable
you really need to see ;-)

 FT> Here is something I don't understand. I have a
 FT> piece of code here where the ONLY difference between a working
 FT> version and a non working version is a write(''); The non working
 FT> version just freezes (past the write(''), by the way). Can anybody
 FT> give a beginning of explanation ? 

I've had similar effects in C / C++. However, I can't give you a real
solution. There are quite a number of possible explanations. It would be
helpful if you could specify what exactly happens in your application. But
among the things that *might* be happening are:

1) You've might have a stack problem. Do calls to other functions have the
same effect, or does _only_ write() change the behaviour of the program?

2) In C, a call to printf() will result in calls to the floating point
libraries and change the status of the floating point coprocessor. In
particular, overflow or other ANSI exceptions will be cleared. If previous
code has set some floating point exception flag in code that was compiled
in such a way that the exception was ignored, the next floating point
exception (probably in a different module that was compiled with different
options) might trap. A printf() in between might clear the flag, so the
problem goes away. I've had troubles with that, although not under DOS.
Does your program "freeze" at a floating point instruction? 

3) In one case, I had strange effects because the linker didn't include a
module from the runtime library even though it was needed by the program.
When including a printf(), the module was referencend and included by the
linker, and the problem went away. If such an effect was responsible for
your problems, the sizes of the two versions of your program should differ
significantly (by more than the 10 or 20 bytes that the write()-call will
compile to).

 FT> I mean it will ship with the extra
 FT> write() if I don't find any other solution, and I repeat the code is
 FT> identical in both compile. The only difference between the working
 FT> code and the non working code is the write('') commented out. 

As long as that bug isn't fully understood, I would feel uncomfortable in
"shipping" that program - I hope it's not a control program for a
nuclear power plant ?!?

 FT> No difference in compiler option or anything ???????????? (PS this only
 FT> happens in the Dos (BP 7.01) version, not in the OS/2 version (either
 FT> VP 1.03b or Speed 1.51)).

Sounds like an interesting bug... best luck. IMHO, a good debugger that
enables you to single step that area of code might help ;-)


Servus, Klaus

Disclaimer: The opinions expressed are solely those of the author.
            And are most probably wrong anyway.

--- FleetStreet 1.18+