1 Feb
2013
1 Feb
'13
6:06 a.m.
On Jan 31, 2013, at 4:52 PM, Random832 wrote:
On 1/24/2013 9:52 AM, Warner Losh wrote:
VAXC would crash and burn, signaling your programming error if you dared try to do this.
On Jan 24, 2013, at 7:42 AM, Ronald Natalie
wrote:
> Amen. For practical matters, there is no way given the rest of the library that an
implementation can do anything other than multiply the two middle args together.
Is there any part of the rest of the library that will be broken if it does something
like call (e.g. on UNIX) fflush (or _flsbuf), fileno, and write in a loop?
vfprintf doesn't call fwrite, so it won't break sprintf.
In theory all I can even think of is if some piece of userspace code made assumptions
about the state of a setvbuf buffer.
Historically the only implementation I know that
didn't just multiply the two args together was on VAX/VMS's VAXC. The underlying
filesystem had a notion of a file of records, so you'd get very different result from
n * size, 1 and n, size.
You might get a different result in terms of the resulting underlying file, and maybe in
terms of performance, but given the requirements the standard puts on fread (which I
don't imagine it would do if a then-prominent implementation violated them), I have
to wonder what would happen, if this is the case, if you attempted to call fread when the
file pointer is positioned on a different sized record, or in the middle of a record.
Because for all the concessions to non-unix-like file
systems the standard _does_ make (binary files may be padded with extra zero bytes
[because they may not be able to be an arbitrary size], text files may have a maximum line
length and may not be able to contain some control characters, heck, _everything_ the
standard says about text files is non-unix-like), it's IIRC rather strict about
"fread has equivalent results to getc in a loop".
The standard makes no such requirements on non-standard files. This behavior had to be
explicitly asked for using non-standard cards/args to open, iirc. However, I think early
versions of VAX C didn't allow a choice and often you'd find you couldn't
do things with files you thought you should be able to. I do believe later versions fixed
this to be more standards conforming, but it was quite a shock to get this behavior when I
first ran into it.
Then again, VAX C wasn't completely standards compliant for most of the time I used
it in college.
Warner