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
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
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.
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 <imp(a)bsdimp.com> wrote:
On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:
On Jan 24, 2013, at 1:02 AM, Larry McVo
As a SPARC guy (in the past), I think it may have
had something to do
That said, I hate the fread/fwrite interfaces. We're fixing them in
our stdio. freadn(f, buf, n).
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. The stream
still needs to be a byte stream
and passing things as void* sort of divorces any
clue as to what
alignment or other portability requirements
are (and I've worked on C on some rather odd
word sized machines like 36
and 60 as well as machines
that encode the word size in the pointer...
believe me there were TONS
of bugs in 4BSD with regard to that
one where they would stuff a char* into a union
and retrieve it with a
int* thwarting any possible conversion
(as we put in place when you casted one pointer
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.
It's not true that FILE went at the end,
except in vararg'd functions.
It goes at the beginning of ftell (which
mimics the UNIX tell call). As with Larry,
I'd much perferred they
mimic'd most of the UNIX calls when
possible. They were reasonably thought out.
TUHS mailing list
TUHS mailing list