Why Your Program Doesn’t Show Latest Output: Understanding Buffering, File Saving, and Linux Debugging

Sometimes when writing and running C programs on Linux, you may notice something strange — you make a change in your program, hit run, and it still behaves like the old version. Or maybe your program prints something, but nothing shows up on the screen. These situations can be confusing, especially for beginners. But they usually have simple explanations related to how Linux handles files, memory, and output.

The Problem of Not Saving Your File

When you edit a file in any text editor — whether it’s VS Code, Vim, or any other tool — those changes are stored in memory until you press “Save”. That means the file on your disk doesn’t actually change until you save it.

So, if you make changes and run the program without saving, Linux will still compile and run the old version of your code. It will not see your new changes because they haven’t been saved to the file system yet.

Always make sure to save the file before running or compiling it. This simple habit can save you a lot of confusion.

How fwrite Works in C

In C programming, when you want to write something to a file or to the screen, you can use the fwrite function. It’s used for binary output — writing blocks of data — but it doesn't immediately write the data to the file or screen. Instead, it stores the data in a buffer, which is just a part of memory used to collect data before writing it all at once.

Why does this happen? Because writing to a file or disk is slower than working with memory. So, instead of writing every small piece of data immediately, C uses a buffer to collect data and write it in one go — this improves performance.

But here’s the catch: the data won’t be written right away. That means if your program crashes or ends early, the buffered data might never get written at all. This is why you sometimes don’t see the output you expect.

Making Sure Output Appears: fflush

If you want to make sure that the data in the buffer is really written out — either to a file or to the terminal — you can use the fflush function. It tells the program to flush the buffer, which means "write everything in the buffer now."

This is especially important when printing to the screen using printf. Sometimes the text doesn’t show up right away because it's stuck in the buffer. Calling fflush(stdout) makes sure the text appears immediately.

You can also use fflush(NULL) if you want to flush all open output streams at once.

Changing Where You Read or Write with lseek

The lseek function in Linux is used to move the file pointer — the current position in a file where reading or writing will happen.

Imagine a file like a long scroll. lseek allows you to move forward or backward to any point in the file. It takes three values:

• The file descriptor (an integer that represents the open file)
• The offset (how far to move)
• A direction (like from the beginning, current position, or end)

For example, if you use SEEK_END, you move to the end of the file. This is useful when you want to append data instead of overwriting it.

Using strace to See System Calls

Sometimes you want to know exactly what your program is doing under the hood — like when it opens a file, reads data, or writes to the screen. That’s where strace comes in.

strace is a Linux tool that lets you trace system calls made by a program. A system call is when a program asks the Linux kernel to do something — like open a file or write to disk.

For example, if you run: strace ./myprogram

You’ll see output like:

open(“file.txt”, O_WRONLY) = 3 write(3, “hello”, 5) = 5

This shows that the program opened file.txt and wrote 5 bytes to it.

If your program is crashing or not doing what you expect, strace can help you see where it’s going wrong. It’s especially useful when you don’t have the source code, because it shows you exactly what the program is doing at the system level.

Watching Library Calls with ltrace

While strace shows system calls (things that go into the kernel), strace shows library function calls. These are the functions your program uses from libraries like the C standard library — for example, printf, malloc, or fopen.

To run ltrace, just do: ltrace ./myprogram

You’ll see output like:

printf(“Hello\n”) = 6 malloc(32) = 0x12345678

This shows what functions are being called, what arguments they are given, and what they return. ltrace is great for debugging problems related to function behavior, memory usage, or when you’re calling external libraries.

Does Overwriting Happen in fwrite or write?

Another important concept is where overwriting happens. When you open a file and use fwrite or write, whether or not it overwrites data depends on how the file was opened.

If the file is opened in write mode (“w”), the existing content is erased before new data is written. If it’s opened in append mode (“a”), new data is added to the end. You can also manually control where the next write happens using lseek.

It’s important to know that fwrite works with buffers, so it doesn’t overwrite the file immediately. The actual overwrite happens during the write system call — when the buffer is flushed.

If you’re not careful with flushing or using the right file mode, you might overwrite data unintentionally or think something was written when it actually wasn’t.

Summary

1. Always save your file before compiling or running it. Unsaved changes don’t exist to the compiler.
2. fwrite writes data to a buffer, not immediately to a file.
3. Use fflush to force output to be written right away.
4. lseek lets you change where the next read or write will happen in a file.
5. strace shows system calls — great for debugging how a program talks to the OS.
6. ltrace shows library function calls — useful for understanding how your code interacts with libraries.
7. File overwriting depends on the mode the file is opened in, and flushing controls when buffered data is actually written.