12

Let's have a look at this Hello World program

#include <stdio.h>
int main(int argc, char ** argv) {
    printf("Hello, World!");

    const char* sFile = "/dev/stdout"; // or /proc/self/fd/0
    const char* sMode = "w";
    FILE * output = fopen(sFile, sMode);
    //fflush(stdout) /* forces `correct` order */
    putc('!', output); // Use output or stdout from stdio.h

    return 0;
}

When compiled using the output file descriptor the output is:

!Hello, World!

when compiled using the stdout file descriptor provided by stdio.h the output is as expected:

Hello, World!!

I figure when calling putc with the latter, it will print directly to the stdout and when using the file descriptor on /dev/stdout it will open a pipe and print into that. I'm not certain though.

The behavior is even more interesting, as it does not overwrite the first character of the 'Hello' but rather pushes itself into the first position of the line buffer in front of the already pushed string.

From a logical point of view this is quiet unexpected.

Can anyone explain what exactly is going on here?


I'm using cc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 and a 3.13.0-52 linux kernel compiled w/ gcc 4.8.2


Edit: I've done an strace of both programs, and here is the important part:

The output (fopen("/dev/stdout", "w")) without fflush(stdout) scenario produces:

...
open("/dev/stdout", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f62f21e9000
write(3, "!", 1!)                        = 1
write(1, "Hello, World!", 13Hello, World!)           = 13
exit_group(0)                           = ?

using fflush(stdout) produces and enforces correct order:

...
open("/dev/stdout", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
write(1, "Hello, World!", 13Hello, World!)           = 13
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5ad4557000
write(3, "!", 1!)                        = 1
exit_group(0)                           = ?

The stdout (from stdlib.h) scenario produces:

...
write(1, "Hello, World!!", 14Hello, World!!)          = 14
exit_group(0)                           = ?

So it seems the FILE * output = fopen("/dev/stdout") stream uses a different file descriptor than stdout Also as it seems printf uses stdout Thus in the third scenario the string is assembled before it is pushed on the stream.

MrPaulch
  • 1,423
  • 17
  • 21
  • `stdout` is a FILE *, not a file descriptor. Similarly, `output` is not a file descriptor. Each has an underlying file descriptor, and if you were to write directly to it you would not see this behavior. (Writing directly to the file descriptor bypasses buffering.) – William Pursell May 19 '15 at 12:33
  • The big difference is that each `FILE*` is using its own buffer, unrelated to each other.. – Some programmer dude May 19 '15 at 13:06

2 Answers2

18

Both of the streams (stdout and output) are buffered. Nothing actually gets written until they are flushed. Since you are not explicitly flushing them, nor arranging for them to be automatically flushed, they are only being auto-flushed when they are closed.

You are also not explicitly closing them, so they're being closed (and flushed) by the standard library's on_exit hooks. And as William Pursell correctly pointed out, the order in which the buffered I/O streams are closed is not specified.

Look at fflush(3), fclose(3), and setbuf(3) manual pages for more information on controlling when and how your output gets flushed.

Gil Hamilton
  • 11,973
  • 28
  • 51
  • 3
    A key point is that the order in which they are being closed is unspecified. – William Pursell May 19 '15 at 12:32
  • Adding a `fflush(stdout)` before the `putc(...)` in the `output` scenario does not change the behavior. – MrPaulch May 19 '15 at 12:33
  • 1
    It does for me, quite reliably. I would recommend running `strace` on your resulting executable to see the sequence of system calls being produced. This can be quite illuminating anyway to see how the buffered I/O functions interact with the system. – Gil Hamilton May 19 '15 at 12:45
  • While officially the order is not specified, on_exit hooks are invoked in the reverse order: ones created later are called first, –  May 19 '15 at 12:53
  • @MrPaulch Your edit has `fflush(output)` , but it should be `fflush(stdout)` – nos May 19 '15 at 13:03
  • @nos Good catch! Thank you. Flushing the stdout does resolve the issue! – MrPaulch May 19 '15 at 13:05
3

/dev/stdout is not the same as /proc/self/fd/0 . In fact, if you have not enough priviledges, you won't be able to write to /dev/stdout as /dev/stdout is not any standard character device in Linux and any attempt to fopen it with the "w" option will try to create an actual regular file on that directory. The character device you are looking for is /dev/tty

In C language, stdout is an initialized global variable of type FILE * which points to the standard output file, that is, the file whose descriptor is 1. stdout only exists in the C namespace and doesn't relate to any actual file named "stdout"

mcleod_ideafix
  • 11,128
  • 2
  • 24
  • 32
  • 2
    I don't know what distro you are using but `/dev/stdout` is a symbolic link to `/proc/self/fd/1` which itself is a symbolic link to `/dev/pts/XX` on mine. So they are interchangable. In the end, that was not even the issue :) – MrPaulch May 19 '15 at 13:23
  • 3
    However, it's worth mentioning that neither /dev/stdout, /proc/self/fd, or /dev/fd are standardized, and /dev/tty is. – Random832 May 19 '15 at 14:00