[TUHS] History of strncpy

[Clem Cole]

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 <imp at 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
> >> about alignment.
> >>
> >> 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 to other).
>
> 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
>
> > 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 at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130124/b82df22d/attachment.html>