Re: read vs fread

From: Patrice Kadionik (kadionik_at_enseirb.fr)
Date: 02/24/05 

Date: Thu, 24 Feb 2005 23:39:23 +0100

Hi Jens,

Jens.Toerring@physik.fu-berlin.de wrote:
> Patrice Kadionik <kadionik@enseirb.fr> wrote:
>
>>Hi all,
>
>
>>I want to make a brief comparison between read() and fread() (under a
>>Linux OS).
>
>
>>1. Family read and Co: open, close, read, write, ioctl...
>>2. Family fread and Co: fopen, fclose, fread, fwrite, fcntl...
>
>
> They are rather different. fread() and co. is built on top of read(),
> so read() is the low level function that the standard C funtions use
> to get their job done. Comparing them is like comparing orange trees
> to orange juice - you don't get juice without first planting the tree,
> picking the oranges etc., but comparing them doesn't really make
> sense;-)
>
Yes, you're right OK.
>
>>Family read and Co:
>>- are not C standard.
>>- are syscalls.
>>- are not formatted IO : we have a non formatted byte stream.
>>- don't use the Linux buffer cache.
>
>
> They don't use the cache created by libc for speeding up reads
> and writes. What do you mean by "Linux buffer cache"?
the linux kernel buffer.
>
>
>>- generally used for accessing character devices. fread and Co is possible.
>
>
> No, they are used for block devices as well.
yes.
>
>
>>Family fread and Co:
>>- are C standard.
>>- are functions of the standard IO libc (glibc).
>>- use an internal buffer (in their coding)
>>- are formatted IO (with the "%.." parameter) for some of them.
>
>
> Well, fwrite() and fread() also don't.
>
>
>>- use always the Linux buffer cache.
>>- generally used for accessing bloc devices.
>
>
> No, they can be used for char devices - actually they are supposed
> to abstract away any dependency on the device (or file or pipe or
> whatever) you're reading from or writing to.
>
>
>>When I'm opening an ordinary file on a HD (bloc device), I'm always
>>using the buffer cache with open or fopen. In case of fopen, I'm using
>>in addition an internal buffer when I'm doing a fread or fwrite for
>>speeding HD access.
>>When I'm opening an character device, I'm not using the buffer cache.
>>Open and Co are generally used here but fopen and Co is possible too.
>
>
> What "buffer cache" are you talking about? There several levels of
> caching. The standard C functions usually do some internal buffering,
> implemented in the libc. You can change that using e.g. the setvbuf()
> function. Then the kernel has some buffers that get used on the next
> stage. You can flush them using the fsync() function. Finally, there
> typically is some more buffering in the hardware of the harddisk it-
> self. But all this doesn't got anything to with the difference between
> block and char devices.
ok. It's clear.
>
>
>>Some points I've forgotten?
>
>
> All standard C functions use a FILE* as the descriptor for the file,
> while all the lower level functions use an integer file descriptor.
> That's where you can easily distinguish between the two groups of
> functions.
> .

I've rewritten my post according remarks from another people:

Family read() and Co:
- are not C standard.
- are Unix, BSD, POSIX and Single Unix Specification standard compliant.
- are wrappers to syscalls.
- are not formatted I/O : we have a unformatted block of one or more bytes.
- don't use a C standard I/O buffer.
- use Linux VFS buffers and cache.
- generally used for accessing data at a low level (device or raw
filesystem format).

Family fread() and Co:
- are C standard.
- are functions of the standard I/O libc (glibc).
- are built on top of low level read() and Co calls.
- use an internal buffer (in their coding).
- enable formatted I/O on some calls.
- use a C standard I/O buffer.
- use Linux VFS buffers and cache.
- are generally used for accessing data streams in a device independant
    fashion.

In general, on Unixish systems, fread() and Co are built on read() and
Co. The implementation of the C 'standard I/O' library functions use the
POSIX I/O syscalls to access data. So, when you use fread(),
etc, you are using read()
The POSIX I/O functions (read()...) do not need or use the C standard
I/O functions.

Thanks;
Pat

Relevant Pages

  • Re: NEW_LINE()
    ... I don't recall ever using text streams in my own code. ... standard, then other non-standard extensions (like some kind ... > I/O can still have a record length limit. ... > a line buffer to be written out with a record mark at the end. ...
    (comp.lang.fortran)
  • 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, ... with a closer reading of the standard i'll concede that it's ...
    (comp.lang.c)
  • Re: read vs fread
    ... are Unix, BSD, POSIX and Single Unix Specification standard compliant. ... are not formatted I/O: we have a unformatted block of one or more bytes. ... don't use a C standard user-space I/O buffer. ... may use Linux VFS buffers and/or kernel-space buffer (depends on what ...
    (comp.os.linux.development.system)
  • 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: read vs fread
    ... readand writedo use the kernel buffer cache (which ... > - are Unix, BSD, POSIX and Single Unix Specification standard compliant. ... The implementation of the C 'standard I/O' library functions use the ...
    (comp.os.linux.development.system)