Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbcad!ames!amdahl!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...)
Message-ID: <31054@sun.uucp>
Date: Fri, 16-Oct-87 00:03:18 EDT
Article-I.D.: sun.31054
Posted: Fri Oct 16 00:03:18 1987
Date-Received: Sat, 17-Oct-87 17:41:52 EDT
References: <855@sugar.UUCP> <29930@sun.uucp> <867@sugar.UUCP> <30458@sun.uucp> <129@nusdhub.UUCP>
Sender: news@sun.uucp
Followup-To: comp.unix.questions
Lines: 56
Xref: mnetor comp.lang.c:4943 comp.unix.questions:4537

> > Why does the SVID stick read() and fread() in the same place?
> 
> I don't know about your system, but on mine you need to supply
> an int to read and a pointer to type FILE [ FILE *fn etc]

Which doesn't answer the question.  I have no idea why they were stuck in the
same place; it certainly doesn't reflect the way this stuff is actually
packaged.  If there is some notion that the stuff in BA_OS should represent
"system calls" (whatever that means - on *some* systems it means "routines
consisting of a tiny wrapper around a trap", but not on others), "fread" - and
"fopen", which is also in BA_OS - certainly doesn't belong there; I know of no
UNIX implementations where "fopen" and/or "fread" are just simple traps.

> The difference is that read() and its brethren use file
> to do all there opperations while fread() and it's brethren use
> streams.
> 
> Apearently every stream has at least one file handle assoicated with it
> but the level and method that streams interact with the kernel
> are quite different than simple files.  That is "any Transport
> Level Interface" [network, etc.] MUST be a stream when you open
> it.  If you want to then use read() against it you must manually
> push a streams-module that will properly react to the read()
> calls.

Unfortunately, the word "stream" is vastly overused when discussing computer
systems, and in particular when discussing UNIX systems.  "stream" is used to
refer to the object that a standard I/O "FILE *" refers to; it is also used to
refer to the object to which a UNIX file descriptor created by opening a
STREAMS device refers.  The two meanings have little to do with one another.  A
standard I/O "stream" can have as its file descriptor a STREAMS "stream", but
it need not, nor need you wrap a standard I/O "stream" around a UNIX "stream".

> I guess what I am trying to say is that, on my system of corse,
> read() and fread() have a different scope.  It is therefore
> approprate that they are listed as read(2) and fread(3S).
> If your system is not "UNIX" read may end up as a library
> refrence, but if it is a library on you computer I don't
> think it's standard.  On the other hand, an "fread" type
> of system-call-primitive is NECESSARY to interact with the
> streams modules in the kernel.  Since SVID includes streams
> definitions, I would assume that fread(2) will soon be the
> new standard, hence SVID may well say read(2) and fread(2)
> [or however they are designating these things].

"fread" has nothing to do with STREAMS (although, if you have a standard I/O
"stream" that refers to a STREAMS device, you can do an "fread" on a STREAMS
"stream"), and it is not a "system-call-primitive".  STREAMS "streams" are
referred to by file descriptors of the same sort as the file descriptors that
refer to regular files, and you can use the same "read" and "write" system
calls on file descriptors referring to STREAMS "streams" as you can on file
descriptors referring to plain files.  As such, "fread" will not "soon be the
new standard", and certainly won't replace "read".
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com