rlb@polari.UUCP (rlb) (05/30/88)
I find it interesting that both K&R (C) and Stroustrup (C++) give I/O package implementation examples in which buffer allocation takes place at the first I/O, rather than in the "open". The obvious disadvantage to this is error detection; the programmer is surprised to discover that although the "open" succeeded, the first I/O fails because of lack of memory (and of course it is usually easier to isolate the open and test its status than to do the same for the first I/O). The only advantage I can think of is that if an "open" is performed but no I/O is requested, you've saved a bit of memory. Are there other advantages? -Ron Burk
ok@quintus.UUCP (Richard A. O'Keefe) (06/01/88)
In article <462@polari.UUCP>, rlb@polari.UUCP (rlb) writes: > I find it interesting that both K&R (C) and Stroustrup (C++) give > I/O package implementation examples in which buffer allocation takes > place at the first I/O, rather than in the "open". [lines deleted] > Are there other advantages? The point is, I believe, to allow you to assign your own buffer. The sequence is fopen() setbuf() | setbuffer() | setvbuf() {IO}
mike@arizona.edu (Mike Coffin) (06/01/88)
From article <462@polari.UUCP>, by rlb@polari.UUCP (rlb): > > > I find it interesting that both K&R (C) and Stroustrup (C++) give > I/O package implementation examples in which buffer allocation takes > place at the first I/O, rather than in the "open". > ... The only advantage I > can think of is that if an "open" is performed but no I/O is requested, > you've saved a bit of memory. Are there other advantages? For one thing, it makes setbuf(3s) possible. You could instead add an optional argument to "open" to specify a buffer, but this mucks up the interface for lots of users who never use setbuf. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
meissner@xyzzy.UUCP (Michael Meissner) (06/03/88)
In article <462@polari.UUCP> rlb@polari.UUCP (rlb) writes: | | | I find it interesting that both K&R (C) and Stroustrup (C++) give | I/O package implementation examples in which buffer allocation takes | place at the first I/O, rather than in the "open". The obvious disadvantage | to this is error detection; the programmer is surprised to discover that | although the "open" succeeded, the first I/O fails because of lack of | memory (and of course it is usually easier to isolate the open and test | its status than to do the same for the first I/O). The only advantage I | can think of is that if an "open" is performed but no I/O is requested, | you've saved a bit of memory. Are there other advantages? | -Ron Burk While I'm firmly in the camp about open allocating the buffer, I will concede that doing the allocation at the first I/O has another advantage: if you use setbuf/setvbuf/setlinebuf/setbuffer on the file, you don't have to do an allocate/free combination to first allocate the default buffer, and switch to the user's buffer. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
bill@proxftl.UUCP (T. William Wells) (06/15/88)
In article <462@polari.UUCP>, rlb@polari.UUCP (rlb) writes: > I find it interesting that both K&R (C) and Stroustrup (C++) give > I/O package implementation examples in which buffer allocation takes > place at the first I/O, rather than in the "open". ... > Are there other advantages? > -Ron Burk Yes. you get better control over buffer usage. For example, once opened, you can assign your own buffer to the file. This would be more complicated if you had to assign your own buffer after the package had already assigned one. > [A comment on allocation failure during I/O.] The packages I am familiar with do not fail if the allocation fails; instead, they just do unbuffered I/O instead of buffered I/O.