Ronald Natalie scripsit: I think it goes at the end in every case except for varargs functions, where we wouldn't be able to know which one was last easily. I like the idea: essentially it's about reading or writing an array of a specified type. -- John Cowan cowan(a)ccil.org http://ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne

On Wed, 23 Jan 2013, Larry McVoy wrote: That syntax makes sense. Though you'd prolly need a "#define fread(b,s,n,f) freadn(f,b,((s)*(n)))", right? For backward compatibility.

On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote: 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. The former would produce one record that was n * size, while the latter would produce n records, each of which was size in length. As with all things on that compiler, this was only sometimes, and it greatly depended on how the file was created... Mostly a royal pain, except in some very rare instances where it was what you wanted to happen. Warner

Ronald Natalie <ron(a)ronnatalie.com> writes: I ported C-TeX to VAX/VMS many years ago, and got a huge performance increase when I swapped the built-in FILE interface to RMS stream files for one I wrote myself, which explicitly did block I/O on RMS binary files instead. That was a fun project. :) -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman

Right on.. Funny, just last week I got into an argument with a VMS person defending Culter's RMS on a DEC mailing list. Here at Intel in NH, many of the old DEC compiler guys still work in the building (and still hack on a FTN compiler to run codes on systems we are still creating). Since, I often eat lunch with them, I just did a little research on the fact from that compiler to verify what I thought I remembered. So I had laughed that you mention that Culter's compiler could on certain cases support RMS. Please remember that it was C and that compiler that forced him to add stream I/O to VMS. As time went on, many ( ?most? ) VMS developers (including the FTN team) stopped using the RMS library and started to use stream since it was >>so<< much easier. To dmr's credit at the time of stdio, record I/O was popular on "enterprise" class systems - ney mainframes of IBM and BUNCH companies. Which is why VMS's I/O system was record based - DEC wanted a piece of that action (and got it). The Multics family widely used the idea of a byte stream and not needing some sort of "facility" or "record" system to do the work; but at the time it was not clear which would "win." So the fact that Dennis was trying to provide an interface that could work on those machines, is again not surprising. I wonder what things todays engineers will get crapped on because it was not clear at the time which way things would go. Clem BTW, I 100% agree that the inconsistency of the interfaces, return codes sins et al, certainly have damaged us. But then again, who knew? Other systems (like VMS) which were much more consistent, but were not as flexible or "open" died, while C, FORTRAN and UNIX live on. On Thu, Jan 24, 2013 at 9:52 AM, Warner Losh &lt;imp(a)bsdimp.com&gt; wrote:

On 1/24/2013 9:52 AM, Warner Losh wrote: 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. 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".