My focus here shall be the following quote taken from the manual description of setvbuf, which startled me:

• If buffer is not a null pointer, instructs the stream to use the user-provided buffer of size size beginning at buffer. The stream must be closed (with fclose) before the lifetime of the array pointed to by buffer ends. The contents of the array after a successful call to setvbuf are indeterminate and any attempt to use it is undefined behavior.

This left me wondering: How will I access my data, which I purposefully store in a buffer to be able to access it independently from my IO stream? Up until that point, I hadn't realised how essential buffers might be, and this question further clarified how central buffers were (TL;DR: since the contents of an IO stream are de-facto undefined until accessed): Why is “while( !feof(file) )” always wrong? I feel like I almost got the answer with this set of information, and yet they seem to contradict each other to me: According to this latter source, I can improve the "unknowability" of my stream by buffering part of it, but I'm rather confident the manual wouldn't implicate a warning of the buffer contents without reason. Is my reading of the manual simply too cautious?

Edit1: Okay, thanks for everyone's comments. Some clarifications: Since functions like fread and fwrite take a buffer as an argument, I assumed setvbuf would be my way of associating a buffer to a stream. I hadn't come across the idea that setvbuf was there to customise the stream's internal buffer, which is a separate thing from the array I'm handling my data in.

My focus here shall be the following quote taken from the manual description of setvbuf, which startled me:

• If buffer is not a null pointer, instructs the stream to use the user-provided buffer of size size beginning at buffer. The stream must be closed (with fclose) before the lifetime of the array pointed to by buffer ends. The contents of the array after a successful call to setvbuf are indeterminate and any attempt to use it is undefined behavior.

This left me wondering: How will I access my data, which I purposefully store in a buffer to be able to access it independently from my IO stream? Up until that point, I hadn't realised how essential buffers might be, and this question further clarified how central buffers were (TL;DR: since the contents of an IO stream are de-facto undefined until accessed): Why is “while( !feof(file) )” always wrong? I feel like I almost got the answer with this set of information, and yet they seem to contradict each other to me: According to this latter source, I can improve the "unknowability" of my stream by buffering part of it, but I'm rather confident the manual wouldn't implicate a warning of the buffer contents without reason. Is my reading of the manual simply too cautious?

Edit1: Okay, thanks for everyone's comments. Some clarifications: Since functions like fread and fwrite take a buffer as an argument, I assumed setvbuf would be my way of associating a buffer to a stream. I hadn't come across the idea that setvbuf was there to customise the stream's internal buffer, which is a separate thing from the array I'm handling my data in.

• c
• error-handling
• buffer
• iostream
• buffering

Share Follow edited Mar 4 at 14:01 Physina asked Mar 4 at 8:04 PhysinaPhysina 1333 bronze badges 8

• 3 "How will I access my data" Your seem to assume that the buffer you provide still is your buffer and you could read and write your data to it. That's wrong. After you hand over that buffer to setvbuf you mustn't access it any longer. – Gerhardh Commented Mar 4 at 8:24
• 1 The last sentence in your quote is: "The contents of the array after a successful call to setvbuf are indeterminate and any attempt to use it is undefined behavior." so what makes you think that you should be able to access the data directly via the buffer that you supplied? – Ted Lyngmo Commented Mar 4 at 8:31
• 1 The use of the buffer by the I/O is transparent to the user. The term buffer is probably misdirecting, it should be interpreted as a data handling structure memory than a pure buffer. The real scope of the function is to permit you to specify not only the size of data reserved memory space, but where to store it. This could be useful on those systems where the dynamic memory, pool or stack, is limited and/or a user localized storage is more effective. – Frankie_C Commented Mar 4 at 8:53
• 1 "How will I access my data, which I purposefully store in a buffer to be able to access it independently from my IO stream?" You don't store anything in that buffer but the C library stores something in that buffer, but you don't know what. The C library can store in that buffer anything in any way it wants. – Jabberwocky Commented Mar 4 at 9:51
• @Frankie_C Especially your mention of limited memory helped me understand why setting this internal buffer would be nice to be able to specify manually -- thanks! :) Just to make sure I got this now: The buffer set by setvbuf() is a different buffer from the "buffer" argument functions like fread() take? I assume the latter would be perfectly safe to access (assuming I protect against overflowing it, etc.)? – Physina Commented Mar 4 at 14:05

 |  Show 3 more comments

1 Answer 1

Sorted by: Reset to default 1

The setvbuf function is used to set up the internal buffer used by the stream specified in the given FILE * object, as well as that stream's buffering mode. This is different from a buffer passed by the user in a call to fwrite for example.

As an example of internal buffering, the stdout stream is line buffered by default. So if you were to do something like this:

printf("hello");

The string "hello" would (most likely) not yet get written to the terminal, but will instead reside in the internal buffer of the stdout stream. Whether or not it actually gets written after the function returns depends on the size of the buffer and what was previously written.