Article View: comp.std.unix
Article #979Buffering?? What buffering??
From: Ronald F. Guilmette
Date: Tue, 02 Jan 1996 00:35
Date: Tue, 02 Jan 1996 00:35
40 lines
2377 bytes
2377 bytes
Submitted-by: rfg@monkeys.com (Ronald F. Guilmette) Greetings and happy new year. I would like to know the exact semantics of the _IOFBF, _IOLBF, and _IONBF mode flags for the `setvbuf' function (subclause 7.9.5.6 of the ANSI/ISO C tandard). Correct me if I'm wrong, but there doesn't seem to be any description whatsoever of the semantics of these flags in the C standard. Given that, I rather wonder why these were standardized at all. Certainly, to just say ``Here are some possible flags for this function. We don't know what they do.'' doesn't help anybody. What does the term ``full buffering'' mean? What are the exact semantics of ``line buffering''? In particular, what is supposed to happen if I attempt (say, using fprintf) to write a ``line'' to a given FILE where the length of the line exceeds the size of the buffer currently associated with the given FILE? What are the semantics of ``no buffering''? In particular, what are the implications for the traditional implementations of the getc and putc macros of setting _IONBF for a given file? Given that traditional definitions of the getc and putc macros (including those which are still in widespread use today) _assume_ buffering, should these macro defini- tions be considered ``broken'' with respect to the ANSI/ISO C standard in the presence of a call to setvbuf which uses _IONBF? (For all you POSIX 1003.1c aficionados out there note that this question also applies equally to the new getc_unlocked and putc_unlocked functions. Are the current implementations of those ``broken'' too?) - -- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------ ---- E-mail: rfg@monkeys.com ----------- Purveyors of Compiler Test Suites - ------ Copyright (c) 1995 by Ronald F. Guilmette; All rights reserved. ----- [ Note the crossposting and Followup-To: line -- mod ] Volume-Number: Volume 35, Number 75
Technical Details
Message-ID:
<4c9uk4$sa4@cygnus.com>Path:
arc1-ca.pugleaf.net!cygnus.com!not-for-mailShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!cygnus.com!not-for-mail From: rfg@monkeys.com (Ronald F. Guilmette) Newsgroups: comp.std.unix,comp.std.c Subject: Buffering?? What buffering?? Followup-To: comp.std.c Date: 1 Jan 1996 16:35:16 -0800 Organization: Infinite Monkeys & Co. Sender: sef@cygnus.com Approved: sef@cygnus.com (Moderator, Sean Eric Fagan) Message-ID: <4c9uk4$sa4@cygnus.com> NNTP-Posting-Host: cygnus.com X-Submissions: std-unix@uunet.uu.net