Hi guys, I am just curious, how can C flush standard streams like stdout when I simply return from main? I mean, to do that doesn't it have to manipulate buffers that are maintained by the standard library? How can it do it and keep the language separated from I/O? I'm implementing some functions from stdio as exercises of the last chapter of K&R2 but to make them work properly I have always to explicitly flush standard streams myself.
Thanks in advance.
qv. setvbuf()
With files, write() is also buffered -- this usually gets flushed when the file is closed. You can set a file O_FSYNC using fcntl() to make writes immediate. I haven't tried this on stdout but feel freeFunction: int setvbuf (FILE *stream, char *buf, int mode, size_t size)
This function is used to specify that the stream stream should have the buffering mode mode, which can be either _IOFBF (for full buffering), _IOLBF (for line buffering), or _IONBF (for unbuffered input/output). If you specify a null pointer as the buf argument, then setvbuf allocates a buffer itself using malloc. This buffer will be freed when you close the stream.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Although it may seem otherwise, main() is not actually the first function that's called (at least, not typically). There's a “hidden” function (often called _start) that is the actual entry-point. It does various setup functions (such as setting up argc and argv), then calls main().
When it calls main(), it's probably something like:
So when your program exits, it actually calls the exit() function, even if you just return from main() (the C standard guarantees this behavior, in fact). If you peek inside of the source code for an exit() implementation, it will probably have some sort of a cleanup facility. FreeBSD, for example, calls __cleanup(); this function (if stdio was used) will flush all the buffers. So as long as libc has control over the startup, it will be able to do the appropriate thing on exit.Code:exit(main(argc, argv));
acctually when you return from main in windows it will call ExitProcess to terminate the program
Regardless of what it's called, the implementation has to behave as if returning from (the initial call to) main() is the same as calling exit() with the same value.
The point, really, is that there tends to be a wrapper around main() so proper teardown can happen. The details aren't important unless you're worried about a particular implementation.
Thanks for all the replies
I see, but wouldn't that tie I/O with the language? I thought they were supposed to be separated.There's a “hidden” function (often called _start) that is the actual entry-point. It does various setup functions (such as setting up argc and argv), then calls main().
Not really, I was just trying to do it myself and wondered how it was done. Although I don't know how can they claim that in C I/O is separated from the language, if the language itself is responsible for doing cleanup of I/O buffers, the way you said, with a wrapper function around main, will work.The details aren't important unless you're worried about a particular implementation.
I am not sure in what context you read the statement that "C I/O is separated from the language", but if I had to guess, it just means that I/O is not part of the core language of C, but rather delegated to libraries, e.g., the C standard library. I find it rather awkward to say that "the language itself is responsible for doing cleanup of I/O buffers". It certainly is not the language that has such responsibility... perhaps we should say "environment".Originally Posted by Aculaniveus
Look up a C++ Reference and learn How To Ask Questions The Smart Way
K&R2 - chapter 7I am not sure in what context you read the statement that "C I/O is separated from the language", but if I had to guess, it just means that I/O is not part of the core language of C, but rather delegated to libraries, e.g., the C standard library. I find it rather awkward to say that "the language itself is responsible for doing cleanup of I/O buffers". It certainly is not the language that has such responsibility... perhaps we should say "environment".
I just thought that for them to be considered separated I would have to explicitly call a library function to do the clean up, the language would have no dealings with the standard library under the hood. I guess when the say "are not part of the C language itself" they only mean that what they are talking about is in the standard library.Input and output are not part of the C language itself
note: when I say I/O buffers I mean the buffers implemented in the stdio (at least in the version presented in the book) so that we don't have to do a system call for every byte read or written, not the hardware buffers or whatever, so I find difficult to see how the environment is responsible for flushing them.
Last edited by Aculaniveus; 01-24-2010 at 10:50 AM.
I suppose it means that the C language (ie syntax) is separate from the standard library (ie fopen, etc). While this is true, the OS actually calls a function in the standard library, so to speak. This function takes care of initializing everything in the library and tearing it down upon termination.
Well, C is the library + language, so you can't have C without having both. It's certainly possible for an implementation to have no obvious separation between the language and the library. That said, many systems do, but there needs to be some sort of glue to put the two together.I see, but wouldn't that tie I/O with the language? I thought they were supposed to be separated.
In fact, your compiler is just blurring the line for you, which makes it hard to see how the two are separate. When you do a simple compile (“cc file.c” for example), your compiler is actually performing two steps: compiling and linking. It's really not until the link phase that the library, and standard I/O, are brought in.
The “mixing” of language and library happens by default because it's useful. Your compiler (or linker) knows that you want to use the standard library, so it arranges to link it in, including the crt (which provides the actual _start routine, or whatever it happens to be called). However, you can probably tell your compiler/linker not to do that: if you're on a system with gcc, try “gcc -nostdlib”; or with gnu binutils, “ld -nostdlib” for the linker.
Your compiler will happily compile code without caring about how the standard library is implemented (try the -c flag to your compiler). But to get an actual executable program somebody has to take care of the _start routine. That can be you, if you really want, or you can let the library take care of it.
