peter@sugar.UUCP (Peter da Silva) (09/28/87)
First of all, the generic System 5 release 2 manual are arranged the same way as the SVID. I haven't seen the release 3 manuals. For that matter I haven't seen release 3. I kind of wish I'd never seen release 2. > The difference is not "'fread' is a library routine" (in fact, > they're *both* library routines on most implementations, one just happens > to be relatively trivial - at least on UNIX systems), Yeh, but we're talking about UNIX systems here. What else would we be doing with a UNIX manual? Read is the UNIX primitive for reading data from a file, and as such it's intrinsically different from fread, which involves a fair amount of code (stdio) that you may want to avoid dragging in (say, because you're running out of space on a PDP-11 or IBM-PC). Other differences between read and fread (and write and fwrite) include: [ I'm sure you're alreday familiar with most of these, but... ] read leaves the I/O pointer pointing at the next byte to read. This is important because of the way UNIX deals with inhertance of file descriptors. Consider the version 6 implementation of "if". writes to a pipe are atomic. fwrites probably aren't. a 1-byte read from a character special device in raw mode will be satisfied by 1 byte. A 1-byte fread may not be. a 1-byte read from a pipe will be satisfied by 1 byte. A one byte fread almost certainly won't be. consider the behaviour of fflush. consider what happens if a program traps out with data still in the buffer. the syntax of fread is different from read (and I consider this a design flaw of the same magnitude as giving bitwise-and its weird priority in 'C'. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
guy%gorodish@Sun.COM (Guy Harris) (09/30/87)
> First of all, the generic System 5 release 2 manual are arranged the same way > as the SVID. Not the on-line versions distributed with VAX S5R2, not the printed ones we got with out VAX S5R2 distribution, not the printed ones somebody here had with an Intel iAPX286 S5R2 distribution, and not the printed ones we got with S5R2 for our 3B2s. All of them put "fread" into section 3, and the system calls into section 2, despite the fact that the SVID puts "fread" and the system calls all into BA_OS. Which allegedly "generic" version are you referring to? > Other differences between read and fread (and write and fwrite) include: All of which are the *intrinsically* significant differences (as opposed to "'fread' drags in more code", which is significant in some cases and not in others), and *none* of which have to do with "fread" being a library routine! "read" could be a library routine (e.g., in Doug Gwyn's S5 emulation package for 4BSD systems) and still have the same characteristics described. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
peter@sugar.UUCP (10/03/87)
In article <29585@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: >>First of all, the generic System 5 release 2 manual are arranged the same way >>as the SVID. >BA_OS. Which allegedly "generic" version are you referring to? I'm afraid we don't have comp.unix.wizards here. If you want to move out of comp.lang.c, how about comp.misc? 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. .... 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. Certainly buffering would be out. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
guy%gorodish@Sun.COM (Guy Harris) (10/04/87)
> 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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/04/87)
In article <855@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >The UNIX System User's Manual. >ISBN 0-13-938242-9 025 I use that for convenience (1 volume instead of 3), but it's horribly organized compared with the real UNIX System V manuals. Prentice-Hall is also publishing what amounts to the generically useful part of the SVR3.0 documentation set in softcover, but there have been reports of typesetting botches that weren't in the SVR3.0 manuals. Since they seem to have the same contents, I wonder how that happened. >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. >Certainly buffering would be out. Well, of COURSE buffering is out, because that's not what read() a la POSIX/SVID is supposed to do! Here's mine: /* read -- system call emulation for 4.2BSD last edit: 16-Jun-1983 D A Gwyn The only reason for this layer is to support O_NDELAY mode. */ #include <errno.h> extern int errno; extern int _read(); /* actual system call */ int read( fildes, buf, nbyte ) int fildes; char *buf; int nbyte; { register int serrno = errno; /* save errno */ register int nread; if ( (nread = _read( fildes, buf, nbyte )) >= 0 || errno != EWOULDBLOCK ) return nread; /* O_NDELAY set and read would block: */ errno = serrno; /* restore errno */ return 0; }
peter@sugar.UUCP (Peter da Silva) (10/08/87)
In article <29930@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > The UNIX System User's Manual. > > The book "UNIX System V Programmer's Reference Manual", from AT&T... Haven't seen the book you cite anywhere. All the bookstores around here have the SVID-based one only. > Presumably, > *this* is what is currently being distributed as the standard manual, not the > one you cite. I wish it was. Unfortunately the book I cite is the only one I've seen, and it's also the one Microport is distributing as their UNIX manual. > 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. I didn't say it was in section 2 or section 3. I said it was in BA_SYS which is as close to section 2 as I can find. If it was in BA_LIB I'd have no problem with it. > 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. Since the title of the message is "System V manuals", don't you think we should be talking about System V? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
guy%gorodish@Sun.COM (Guy Harris) (10/09/87)
> Haven't seen the book you cite anywhere. All the bookstores around here > have the SVID-based one only. Well, that's too bad, but the book *you* cite appears to be the only book that claims to be a System V manual (as opposed to a System V interface definition) and that has this layout. In other words, the book you cite is an exception to the rule, and complaints about its contents cannot validly be extended to complaints about System V documentation in general. > I wish it was. Unfortunately the book I cite is the only one I've seen, > and it's also the one Microport is distributing as their UNIX manual. It's not the one AT&T is distributing as *its* UNIX manual, nor is it, I suspect, what most vendors distribute. > I didn't say it was in section 2 or section 3. I said it was in BA_SYS... I quote here from your original article: > Except that the O/S *manuals* follow the SVID. And except that it confuses > people. "Hey, peter, how come they have read and fread?" "Well, fread is > a library routine." "Oh. How do you tell which ones are library routines?" > "read the manual. Library routines are section 3" "section 3? I don't > have a section 3" "What? Let me look at that... they must be kidding". I see nothing about BA_SYS here. I see only a claim that "the O/S manuals follow the SVID", which is NOT true in general; it is only true for that one anomalous manual you saw. All the System V manuals we've gotten from AT&T have the traditional division between sections 2 and 3. > > 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. > > Since the title of the message is "System V manuals", don't you think we > should be talking about System V? Well, first of all, if we're talking about System V, we should talk about it in comp.unix.questions, so this discussion is moving there. Second of all, in the claim you made said nothing about implementing "read" under a vanilla System V system. You just said > 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. Certainly buffering would be out. with no such qualification. You could definitely do this under some non-vanilla implementations, e.g. Apollo's DOMAIN/IX. For that matter, you could probably do it under vanilla System V, if the IPC code, including shared memory, is configured into the kernel. You may not *want* to do it that way, but it's not impossible. The fact that it *doesn't* happen to be implemented that way in most UNIX systems is irrelevant; you didn't say it *wasn't* done that way, you said that you didn't believe it *could* be done that way. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/10/87)
In article <867@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Since the title of the message is "System V manuals", don't you think we should >be talking about System V? The read() library source I posted existed solely as part of a package for which the System V manuals apply. This is a stupid discussion!
peter@sugar.UUCP (Peter da Silva) (10/14/87)
You can go anywhere you like. Since we don't get comp.unix.questions I'll never see it. Don't forget to write :->. In the meantime... In article <30458@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > [ it's not the REAL system V manual ] Fine. They wised up. I'll keep an eye out for something better. > > I didn't say it was in section 2 or section 3. I said it was in BA_SYS... > I quote here from your original article: That was in my original article, but what about the half dozen iterations since then... > > Except that the O/S *manuals* follow the SVID... > > "read the manual. Library routines are section 3" "section 3? I don't > > have a section 3" "What? Let me look at that... they must be kidding". That doesn't say BA_LIB, either. That just says it's not in a section 3. I'm sure I mentioned BA_SYS somewhere. Anyway, here's a real question: Why does the SVID stick read() and fread() in the same place? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/15/87)
In article <876@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > 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] 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. 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]. Robert.
guy%gorodish@Sun.COM (Guy Harris) (10/16/87)
> > 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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/19/87)
In article <129@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >If you want to then use read() against it you must manually >push a streams-module that will properly react to the read() >calls. The explanation from which the above was extracted is totally bogus. read() and fread() are not necessarily associated with STREAMS (AT&T terminology), but fread() is associated with a "stream" (ANSI C terminology), which is nothing more than data accessed via a FILE structure.