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?

Thanks.

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_FILE_LENGTH 40
#define MAX_STRING_LENGTH 100

int main(void)
{
    int count, file_length, string_length;
    char filename[MAX_FILE_LENGTH], line[MAX_STRING_LENGTH];
    FILE *openfile;

    puts("Enter file to open");
    fgets(filename, MAX_FILE_LENGTH, stdin);

    string_length = strlen(filename);

    filename[string_length-1] = '\0';

    puts(filename);

    if ((openfile = fopen(filename, "r")) != NULL)
        puts("File opened successfully\n");

    else
        {
            puts("Error opening file");
            exit(1);
        }

    while(fgets(line, MAX_STRING_LENGTH, openfile ) != NULL)
        {
            printf("%s", line);
        }

    fclose(openfile);

    return 0;
}

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).

Originally Posted by whiteflags

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?

Originally Posted by grumpy

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

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

Originally Posted by grumpy

how fgets() works

cfanatic take a look in here fgets - C++ Reference

Code:

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.

Originally Posted by cfanatic

Does fgets() put it all on the stack?

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.

Originally Posted by cfanatic

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);

Originally Posted by grumpy

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 file).
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

Originally Posted by whiteflags

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

Yep, this appers to be the case. I have a large paragraph, and it is outputting chunks of the paragraph at a time, so I guess the buffer was full and getting flushed.

Originally Posted by std10093

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 file).
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.

Originally Posted by cfanatic

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

Your welcome.Glad to hear that,because this means that you like it Maybe you can teach me how to use it in the future :-D

Originally Posted by std10093

Your welcome.Glad to hear that,because this means that you like it Maybe you can teach me how to use it in the future :-D

Right now I only know how to watch the values of local variables. Still have to to learn how to set breakpoints and and whatever else is involved with debugging.

There are a couple of ways that I know.

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.

Originally Posted by grumpy

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.