C: _IOLBF for input?

[Solar]

Something I stumbled over in the context of PDCLib, and which I would like to bounce off you folks here.

In the C standard lib, you can set a stream to be _IONBF (not buffered), _IOLBF (line buffered), or _IOFBF (fully buffered), using the setvbuf() function.

Now, for output the results are pretty clear: Write out immediately, after a line feed, or when the buffer is full, respectively.

But for input... I mean, _IONBF and _IOFBF are easy enough. But what about _IOLBF? How should I do line-buffered input without ending up reading the input char-wise and checking for linefeed each time?

Are there kernels out there that offer system calls for line-wise input, and what do they look like?

Right now, I don't see sense in _IOLBF for input streams, and would implement this buffering mode as equivalent to _IOFBF. Opinions?

[Combuster]

Kernel calls involving actual lines, not that i know of.

However, consider the possibility of reading an UDP connection as a stream (wether UDP can be seen as a stream is a different subject). Its difficult to ask the kernel to get the result per byte, and for completely filling the buffer you might start waiting for packets that are not there, for whatever reason. Hence a system built on that would buffer one packet and stream it out to the user, which could be in some sense considered 'line buffering' for being the middle way between no buffering and full buffering.
Hence, you could see the socket read() as a line operation.

Similarly, reading from a keyboard stream would cause waits when the code would force to fill the buffer. Or when downloading from the internet, line buffering can be useful to do parsing while only part of the message has arrived. (or when the next set of data will only arrive later: think IRC, MSN where such behaviour can be rather useful)

[Solar]

Kernel calls involving actual lines, not that i know of.

That's what I thought. I'll wait a bit to hear if others have heard of such, but I don't hold my breath.

About the rest, that doesn't really apply. For cases like reading from socket or keyboard, fread() for example returns the number of items actually read, which might well be less than the number requested. Traditionally, you keep calling fread() until you get EOF, or an error. Library-space buffering is unaffected by this.

[Candy]

Something I stumbled over in the context of PDCLib, and which I would like to bounce off you folks here.

In the C standard lib, you can set a stream to be _IONBF (not buffered), _IOLBF (line buffered), or _IOFBF (fully buffered), using the setvbuf() function.

Now, for output the results are pretty clear: Write out immediately, after a line feed, or when the buffer is full, respectively.

But for input... I mean, _IONBF and _IOFBF are easy enough. But what about _IOLBF? How should I do line-buffered input without ending up reading the input char-wise and checking for linefeed each time?

Are there kernels out there that offer system calls for line-wise input, and what do they look like?

Right now, I don't see sense in _IOLBF for input streams, and would implement this buffering mode as equivalent to _IOFBF. Opinions?

I know that Linux by default buffers full lines on stdin - either linux or glibc that is. It could be that they send a flush-to-user bit along with a newline character, something like that. Pretty sure it's linux itself though, using read() on fd 0.