Automatic flush of standard streams in stdio

This is a discussion on Automatic flush of standard streams in stdio within the C Programming forums, part of the General Programming Boards category; Hi guys, I am just curious, how can C flush standard streams like stdout when I simply return from main? ...

  1. #1
    Registered User
    Join Date
    Jan 2010
    Posts
    7

    Automatic flush of standard streams in stdio

    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.

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    qv. setvbuf()

    Function: 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.
    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 free
    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

  3. #3
    cas
    cas is offline
    Registered User
    Join Date
    Sep 2007
    Posts
    993
    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:
    Code:
    exit(main(argc, argv));
    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.

  4. #4
    Registered User
    Join Date
    Jan 2010
    Posts
    34
    acctually when you return from main in windows it will call ExitProcess to terminate the program

  5. #5
    cas
    cas is offline
    Registered User
    Join Date
    Sep 2007
    Posts
    993
    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.

  6. #6
    Registered User
    Join Date
    Jan 2010
    Posts
    7
    Thanks for all the replies

    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().
    I see, but wouldn't that tie I/O with the language? I thought they were supposed to be separated.

    The details aren't important unless you're worried about a particular implementation.
    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.

  7. #7
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,265
    Quote Originally Posted by Aculaniveus
    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.
    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".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #8
    Registered User
    Join Date
    Jan 2010
    Posts
    7
    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".
    K&R2 - chapter 7
    Input and output are not part of the C language itself
    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.

    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.

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,007
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    cas
    cas is offline
    Registered User
    Join Date
    Sep 2007
    Posts
    993
    I see, but wouldn't that tie I/O with the language? I thought they were supposed to be separated.
    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.

    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Abstract Base Class and References
    By Thantos in forum C++ Programming
    Replies: 9
    Last Post: 10-13-2004, 02:35 PM
  2. im extreamly new help
    By rigo305 in forum C++ Programming
    Replies: 27
    Last Post: 04-24-2004, 12:22 AM
  3. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 04:49 AM
  4. How to Flush standard input?
    By Hardboy in forum C++ Programming
    Replies: 7
    Last Post: 02-21-2003, 03:30 PM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21