Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucsdhub!jack!man!nusdhub!rwhite From: rwhite@nusdhub.UUCP (Robert C. White Jr.) Newsgroups: comp.unix.questions Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...) Message-ID: <133@nusdhub.UUCP> Date: Fri, 16-Oct-87 13:46:30 EDT Article-I.D.: nusdhub.133 Posted: Fri Oct 16 13:46:30 1987 Date-Received: Sun, 18-Oct-87 00:07:27 EDT References: <855@sugar.UUCP> <29930@sun.uucp> <867@sugar.UUCP> <30458@sun.uucp> <31054@sun.uucp> Organization: National University, San Diego Lines: 78 Summary: What?.... Whare did that come from. In article <31054@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > "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"), Apparently I needed to use upper case. On my system "STREAMS" are not defined when compared with read() in many cases [most spesifically network "STREAMS" module(s)] The fact that you "can do fread on a "STREAMS" stream" was quite my point. > and it is not a "system-call-primitive". Also, quite my point. It is not NOW a system call primitive, it is a library routine, thats why I SAID FREAD(3S)!. > STREAMS "streams" are > referred to by file descriptors of the same sort as the file descriptors that > refer to regular files, It is therefore strange that my programmers refrence refers to a function: int fileno(stream) FILE *stream; under FERROR(3S) which: "returns the interger file descriptor associated with the named _stream_ 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. I have been given to beleive that this is not the case. The C use of read() on "STREAMS" such as standard input _BYPASSES_ the STREAMS module and drivers and gets the file handle from the lib, and uses it on the file directly. The same holds true for "normal" files. If you use this on a STREAMS-only device the bypassing of the stream device lets you read the transport provider [in the case of networks] directly, dropping you two or more layers in the 7-layer model. if you want to read() the data you need to tpush() the approprate emulator on the STREAMS-head. If you don't, you get trash, and if you do, you are locked out of most of the STREAMS functions until you tpop() the module off. [For more information, get a book on using the Transport Level Interface] NOTE: when you use a _multiplexing_ stream head to deal with iregular input from multiple sources as if it were a single source, I havn't got the foggiest what read() does. > As such, "fread" will not "soon be the > new standard", and certainly won't replace "read". FORTUNATELY THIS IS _NOT_ WHAT I SAID.... WHERE DID YOU GET _"replace"_ ??????????! I SAID: that finding read(2) AND fread(2) may soon be the new standard. YOU WILL PLEASE NOTE THE _AND_, "2"s, AND THE LACK OF A PERIOD, OR OTHER DISTURBING PUNCTUATION IN THAT SENTENCE. YOUR "ORIGINAL" RESTATED QUESTION WAS "why are read() and fread() in the same place?" (in SVID) THIS IS THE QUESTION I ANSWERED HERE, AS SUPPOSITION, NO LESS. If you are using vnews, I seguest you use "p" once or twice and read the paragraph again. IN THE FUTURE I WOULD APPRICIATE IT IF YOU WOULD DO THE FOLLOWING: 1) ONLY QUOTE ME IN CONTEXT. 2) READ BEFORE YOU FLAME. 3) CHECK YOU MANUAL FOR _REFRENCES_ BEFORE YOU FLAME 4) STOP TAKING EVERYTHING SO PERSONAL. Rob. p.s. To anybody my previous posting confused, aparently I SHOULD have used the uppercase when writing "streams". If it's that important, just read every occurance of "streams" as "STREAMS"