The mystical art of debugging

This is a discussion on The mystical art of debugging within the C Programming forums, part of the General Programming Boards category; Hi all. I am learning how to use the debugger.
Here is a program that I wrote in the early ...

The mystical art of debugging

Hi all. I am learning how to use the debugger.

Here is a program that I wrote in the early days of learning C for displaying the contents of a text file to the screen.

I had always thought that it would grab 100 characters of a line(at a time) and then output to the screen, looping repeatedly, until fgets() == NULL. To my surprise, it seems to be storing several lines somewhere, and then only outputting them when fgets() == NULL. So it seems to output only once. Why is it doing this, and how can it be doing this when the buffer size is only 100?

Put a breakpoint on the while and watch line, then step for some time, what is happening? That should prove things to you.

I think your program works correctly, the results are just what you end up experiencing. The screen is buffered so you will probably see the entire file at once, or huge blobs of text appear at once (if you actually bump against the console's buffer size) rather than a line by line progression like a video game. All those delays are artificially made.

What has the title "mystical art of debugging" got to do with your problem?

In any event, you need to read up more carefully on how fgets() works, in particular when a '\n' (and a terminating '\0') is included in the buffer, and when it is not. Compare that with what your screen does with long lines (a lot of screens simply discard the data on very long lines).

If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

Put a breakpoint on the while and watch line, then step for some time, what is happening? That should prove things to you.

line does store 100 characters at a time(as expected), but the 100 characters changes constantly when I step through the loop, and there is no output while this happens. And then everything is dumped to the screen. Where are all the multi x 100 characters stored? It's dumping about 2000 characters, so they must all be stored somewhere? Does fgets() put it all on the stack?

Reads characters from stream and stores them as a C string into str until (num-1) characters have been read or either a newline or the end-of-file is reached, whichever happens first.
A newline character makes fgets stop reading, but it is considered a valid character by the function and included in the string copied to str.

No. stdout (which is used by printf()) is buffered, and one of the conditions for clearing the buffer is '\n' characters in output. You may also, if your file contains long lines, see things missing due to how your output device (screen) handles long lines.

Originally Posted by std10093

He was strongly guided in another post to learn how to use a debugger,so he might be influenced by that

That doesn't justify using subject lines for threads that are unrelated to content of posts.

If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

line does store 100 characters at a time(as expected), but the 100 characters changes constantly when I step through the loop, and there is no output while this happens. And then everything is dumped to the screen. Where are all the multi x 100 characters stored? It's dumping about 2000 characters, so they must all be stored somewhere? Does fgets() put it all on the stack?

Well, it's being stored in a low level buffer somewhere, and the output is flushed when the buffer is full, most likely.

If you have to see something, force the characters to be written to the screen with fflush(stdout);

That doesn't justify using subject lines for threads that are unrelated to content of posts.

True,so cfanatic will be more careful next time :-D

Also cfanatic my roomate is learning C now and they had as topic today the gnome debugger.I will copy paste a list of commands you use in the terminal in order to play around with gdb

Code:

debugger (gdb) commands
Most frequently used gdb commands (ask the man page)
run | Start your program.
quit | Exit from gdb.
help | Show information about command names and classes (e.g. help
breakpoints).
print | Display the value of an expression.
display | Print value of an expression each time the program stops.
continue | Running your program (after stopping).
next | Execute next program line (after stopping); step over.
step | Execute next program line (after stopping); step into.
return | Execute until caller (after stopping); step back.
break | Set a breakpoint at function (in ﬁle).
list | type the text of the program in the vicinity of where it is presently
stopped.
backtrace | display the program stack.
up | Select and print stack frame that called this one.
down | Select and print stack frame called by this one

in an IDE of course you have them visualized with elegant figures but i thought it might be helpful to know some things about it

Also cfanatic my roomate is learning C now and they had as topic today the gnome debugger.I will copy paste a list of commands you use in the terminal in order to play around with gdb

Code:

debugger (gdb) commands
Most frequently used gdb commands (ask the man page)
run | Start your program.
quit | Exit from gdb.
help | Show information about command names and classes (e.g. help
breakpoints).
print | Display the value of an expression.
display | Print value of an expression each time the program stops.
continue | Running your program (after stopping).
next | Execute next program line (after stopping); step over.
step | Execute next program line (after stopping); step into.
return | Execute until caller (after stopping); step back.
break | Set a breakpoint at function (in ﬁle).
list | type the text of the program in the vicinity of where it is presently
stopped.
backtrace | display the program stack.
up | Select and print stack frame that called this one.
down | Select and print stack frame called by this one

in an IDE of course you have them visualized with elegant figures but i thought it might be helpful to know some things about it

Thanks for the info. I am debugging in Code::Blocks(using gdb). I'll be using IDE debugging for the rest of my life.

Click between the number lines and the code to set a breakpoint.
Or you can set the text cursor amid a line and access Debug -> Toggle breakpoint.
Or you can set the text cursor amid a line and press F5.

Actually the hardest way to set a breakpoint in the world may be with a poorly suited editor and a command line interface. It can be hard to set breakpoints that way when there is basically no line numbering. I guess most IDEs make it easy.

That doesn't justify using subject lines for threads that are unrelated to content of posts.

With all due respect (since grumpy is one of my favorite posters) I like the subject line. It may be a little overly-creative, but at least it says something about the contents. What I hate are all the "help me" subjects. They show no thought at all and are utterly useless.

On using debuggers, it seems to me that they aren't introduced to students early enough (or at all). They are a great way to deepen your understanding and should be introduced as early as possible.