Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...)
Message-ID: <29930@sun.uucp>
Date: Sat, 3-Oct-87 23:01:36 EDT
Article-I.D.: sun.29930
Posted: Sat Oct  3 23:01:36 1987
Date-Received: Wed, 7-Oct-87 04:00:07 EDT
References: <855@sugar.UUCP>
Sender: news@sun.uucp
Lines: 60

> Anyway, after a couple of tries at getting to comp.unix.wizards, here's the
> info.
> 
> The UNIX System User's Manual.
> Copyright (c) 1986 by AT&T. All rights reserved.
> Published by Prentice-Hall.
> ISBN 0-13-938242-9 025
> 
> This book is being distributed nationwide as the "standard" SV manual. If
> it's wrong, there's something really strange going on.

The book "UNIX System V Programmer's Reference Manual", from AT&T, published by
Prentice-Hall, ISBM 0-13-740479-1 025, has "fread" in section 3S.  Presumably,
*this* is what is currently being distributed as the standard manual, not the
one you cite.  That one may have been the manual they distributed at one time.
I vaguely remember one such manual which was really a reprint of the SVID, and
as such had "fread" neither in section 3S nor in section 2, but in section
BA_LIB.

If the manual you cite was a reprint of the SVID - or even if it had "fread" in
section 2 - then, well, yes, it is wrong, or at least it is not the standard
UNIX manual.  Nothing strange was necessarily going on; AT&T is a big company
consisting of several parts, and one particular part frequently doesn't know
what's going on in other parts.  Somebody may have had the bright idea of
publishing the SVID as a UNIX manual, and somebody else may have thought better
of it later.

> I don't believe you could implement "read" as a library routine and retain
> the attribute of leaving the file descriptor at the point last read, unless
> you were to "implement" it by making a direct call to the existing read
> routine.

How direct is "direct"?  The one I cited, from Doug Gwyn's compatibility
package, eventually does make a call to a routine that is a system call wrapper
just like the existing "read" routine" (having a routine named "read" call the
existing "read" routine *by that name* would require some trickery), but did
more than than - it mapped certain error returns into S5-style returns.

> Certainly buffering would be out.

Certainly buffering would *NOT* be out.  Apollo's "read" is implemented as a
user-mode routine that calls their user-mode routines implementing their
object-oriented I/O system; those routines end up doing I/O by mapping the
underlying file into the process' address space and copying data to and from
its pages.  I presume the file pages in question would be multiply mapped (they
certainly *could* be) so that if process A modifies some data in this "buffer"
process B would see the modification as well.

Also, you're wrong if you don't believe you could implement "read" as a library
routine and preserve the shared file pointer.  In a system such as Apollo's,
file descriptors could be implemented as indices into an array containing
pointers to *shared* data, so that if process A moves the file pointer it
affects the file pointer seen by process B as well.

Remember, we're NOT just talking about "traditional UNIX systems" here.  This
"read" could be implemented atop a non-UNIX system, or a UNIX system with more
general facilities for sharing than "traditional" systems.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com