Kaz Kylheku <firstname.lastname@example.org> writes:
Post by Kaz Kylheku
"The buffer size is 2ᴺ kilobytes, where N is specified as a decimal digit."
Of course it occured to me right from the beginning that an arbitrary
buffer size could be specified if we require an integer token to be
lexically scanned; I rejected the low-brow idea and searched for a
compact representation in one character which harmonizes with the
existing terse design of the mode string. It had to have a convention
that is easy to remember and a reasonable dynamic range.
I don't think "low-brow" is particularly meaningful.
The problem you're addressing is that setvbuf() must be called (almost)
immediately after fopen(), so there's not much point in separating them.
You want to add information to fopen() in a compatible manner, that lets
the user combine the fopen() and setvbuf() calls. The proposal is meant
to be convenient, but does not cover all cases. In particular, it only
permits a particular set of buffer sizes (encoded in a single decimal
digit), and it can't be used with stdin, stdout, stderr, or other files
for which the user can't modify the fopen() call.
Is that a fair summary, or have I missed something?
My objections to the proposal are:
1. The set of allowed buffer sizes is arbitrary. It might cover most
useful cases -- for now. Future developments might (or might not)
change the set of useful buffer sizes.
2. The syntax, though it's easy it explain, is not intuitive.
3. It's far less flexible than calling setvbuf() after calling fopen().
A user can easily write a function that does both without needing an
update to the standard library.
4. Code that uses the new feature, when used with an implementation that
doesn't support it, will not necessarily be detected at compile time,
and its behavior will be undefined. Compilers might emit warnings,
but that requires knowing whether the runtime library supports the
feature, something that might not always be possible.
I suggest that a call to fopen() immediately followed by a call to
setvbuf(), as permitted by the current standard, is clearer, which
IMHO suggests that the proposed new feature is not very useful.
On the other hand, setting the buffer size and buffering behavior
is logically something that should be associated with opening a file
(though changing the buffering of pre-opened streams can also be
useful). If I were designing an I/O library from scratch, I'd probably
include that functionality in the file open function(s), while making it
as easy as possible to use default settings.
Another approach would be to define a new function that combines fopen()
and setvbuf(). As a starting point;
const char *path,
const char *mode,
though I don't necessarily suggest that specific declaration. And
again, a programmer can easily define such a function without changing
the standard library.
Keith Thompson (The_Other_Keith) email@example.com <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"