Re: Unix I/O and C library I/O, why there are two sets of I/O functions?

On 2006-02-07, Eric Sosman <esosman@xxxxxxxxxxxxxxxxxxx> wrote:
Jordan Abel wrote:

On 2006-02-06, SM Ryan <wyrmwif@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

# Bear in mind also that fread() returns the amount of data requested, if
# possible, whereas read() gives you no such guarantee. A lot of the time,
# you have to write more code to use the low-level calls.

Other way around. In Unix, read() gives the number of bytes read
or an error indication. fread returns the number of complete items,
but in case of a partial item of more than one byte, you don't
know how many bytes were read.


There _isn't_ a partial item, as far as fread() is concerned - the bytes
that would be a "partial item" are still in the buffer, and can be
subsequently read with getchar().

Are you sure of that? Can you cite chapter and verse?

It seems to me this would be an onerous requirement,
considering that support for fseek()/fsetpos() is not
guaranteed for all streams.

Nor is it necessary. fread does not need to be implemented in pure
standard C. To suppose that it's "getc in a loop" is naive.

Lacking seekability, making the characters of the partial item
accessible to getchar() would seem to require a buffer of
sizeof(item) -- which could, of course, be as large as (size_t)-1.
I suppose one could get away with a 32KB (C90) or 64KB (C99)
buffer, at the cost of restricting object sizes to the bare minima
the Standards require, but ...

Or allocate a buffer on the stack within fread. It's unlikely to
actually be too large, given that the user also has to have
allocated a whole array of items in the given size.

Anyhow, I don't see "getc() can retrieve the bytes of a
trailing partial item" requirement anywhere in C99. Can you
explain where you find it?

Well, with a closer reading of the standard i'll concede that it's
not the case when using a stream that isn't seekable, but

The file position indicator for the stream (if defined) is advanced
by the number of characters successfully read. /* i'm assuming that
characters which are part of a partial item are not "successfully
read". */
.

Relevant Pages

  • Re: read vs fread
    ... fread() and co. is built on top of read, ... >>using the buffer cache with open or fopen. ... The standard C functions usually do some internal buffering, ... are not formatted I/O: we have a unformatted block of one or more bytes. ...
    (comp.os.linux.development.system)
  • Re: Why GCC does warn me when I using gets() function for accessing file
    ... that on my system int is 17 bits or more, I can guarantee I haven't [invoked ... The C standard says nothing about such ... it actually overruns the buffer. ... to be well defined the spec has to specify something ...
    (comp.lang.c)
  • Re: Unix I/O and C library I/O, why there are two sets of I/O functions?
    ... as far as fread() is concerned - the bytes ... that would be a "partial item" are still in the buffer, ... To suppose that it's "getc in a loop" is naive. ... with a closer reading of the standard i'll concede that it's ...
    (comp.lang.c)
  • Re: CString help
    ... But maybe because I don't see the guarantee of contigous space ... the fact remains that the technique writes into a buffer ... Even if the buffer is required to be contigous by the standard, ...
    (microsoft.public.vc.mfc)
  • Re: Unix I/O and C library I/O, why there are two sets of I/O functions?
    ... whereas readgives you no such guarantee. ... as far as fread() is concerned - the bytes ... that would be a "partial item" are still in the buffer, ... It seems to me this would be an onerous requirement, ...
    (comp.lang.c)