Maybe now that DBG is said to be operational again i will encounter less problems.
However i have lost hours(days really) on finding a bug that was just a print statement in
a backfill hook function.
I also had trouble with printstatements (PutStr) in the library and interface closing code.
In code using the pipe functions i learned that PutStr() is safe, and Printf freezes the system. How about the experience of old hands?
@JosDuchIt
Better use DebugPrintF() always for debug output because it can also be used in cases where you can't use dos.library functions.
Not sure what you are doing here but the main difference between Printf() and PutStr() apart from the obvious one that Printf() allows formatting options while PutStr() doesn't is that Printf() is a buffered i/o call (like FWrite() f.e.) while PutStr() isn't (like Write()). The buffering means obviously that data is not necessarily written to the Output() filehandle immediately (you can use FFlush() to force it to be written).
Checking what i did use : it was not PutStr but the function
PrintStr() suggested to me by Joerg van de Loo (bareEd author)
I am not able to comment on why this one behaves better
Thanks for the suggestion.
Starting from code i borrowed from D Keletsekis
i did also use the following include debug.h
You can add more defines similar to MYDEBUGA & B
The idea is to taylor the debugging output to problem at hand
When compiling debugged code, i either do not include debug.h
or modify below
#define MYDEBUG 1
and all others to 0 (if leave some of them to you just get some warnings)
(I do check first if Da( Db( do not appear in the code to debug.)
@JosDuchIt
Actually checking the autodoc again I was wrong and PutStr() is buffered too (your PrintStr() function isn't though).
TBH unless you post some code of how you use Printf() and how you replaced it with PrintStr() function it's pretty hard to guess what exactly you are trying to do and what you are doing wrong. F.e. it could be as simple as the fact that your PrintStr() is able to "handle" a NULL value of "text" parameter thanks to mystrlen() function. IMHO though if you have a string pointer you want to print which may or may not be NULL your better off doing something like this:
PutStr(text ? text : "(null)");
PutStr("\n");
or more advanced:
Printf("Text: %s\n", text ? text : "(null)");
In this case you are not dependant on how the function used to print text handles a NULL value, which is usually not documented, and especially bad to do if your code uses an ansi function like printf() where implementation will vary depending on what compiler and C library is used.
@salass00
Thanks for the suggestions, especially the warning for printf
In fact i did expect reactions to be more like " o yes don't use print statements of any kind here and there, because of sideffects, race conditions and the like"
So i will give successive examples of print statements that generated crashes and were not trying to print a NULL pointer
For sure i did an overkill of debug prints in the closing of libraries below, but why the PutStr generated systematic freezes remains unclear to me. I indeed had to comment out the print stements in sequence, the crashings were displaced from one DropInterface to the next, whera the print output just before the drop never succeeded.
I had trouble also with print statements in trying to fix a piper() function that is the heart of the implementation of an xPIPE event in Gui4Cli
In Gui4Cli language the program would have some lines like
xPIPE MyPipe ON // or off
;// now here, the internal var $$PIPE.TXT has a line of text ir somebody wrote to the pipe
;// ready for us. We can output it to the Gui4Cli output console with
Say $$PIPE.TXT
In the original (SAS compilable pre-OS4) source The function looked like this
Compiling for OS4 (with (__USE_INLINE__) there were no crashes but the xPIPE event did no longer produce the expected output. When you tried to direct the lines put into the MyPipe from CLI with
>> More <PIPE:MyPipe
there seemed to be an output of empty lines, but repositioning the cursor in the shell those 'lines' disappeared.
After you quitted the program (without quitting Gui4Cli) the same shell command did show what had been written to the pipe.
(Quitting Gui4Cli without having emptied the pipe is not possible)
Using some kind of print statement in the source code produced output only before the line
// ---------- read in a line - length shorter than buffsize for safety
This output was directed not to the Gui4Cli console but to another output window.
As the goal of the function is to direct output to the latter there may be some interaction i don't understand whch is preventing this.
Since i came (today) to this insight, i removed all kind of print statements in the function.
To no avail.
I have followed advice using (buffered) FOpen instead of Open and still have the same problem.
I am out of ideas how to tackle this one.
Any help much appreciated (also on how maybe GDB could be used here)
Oh yes: at a certain moment playing with MyPipe as well from shell as from the program (you can CLEN (empty) the pipe, set it of or on, the pipe output appeared where it was expected.
I was unable to replicate that however.
I know that PrintF() will crash if you don't pass it a format arguments table pointer even if your string has no formatting or arguments.