[... reformatted for line length ...]
I want to be sure what these two functions are for. To copy for
example 1 2048 size bytes block at a time? I usually use fgetc and
fputc. But I would please like for someone if they would to show me
an example of these functions.
They are "convenience functions" in the sense that you could
use repeated calls to fgetc/fputc (or getc/putc) to do pretty much
the same thing, transferring one byte per call. Since you transfer
(potentially) many bytes per call fread/fwrite could be a bit faster
than byte-at-a-time loops, but since most CPU's are millions of times
faster than most I/O devices any gains are unlikely to matter.
Here's a closer look at fread; fwrite is similar. First,
the declaration (slightly simplified):
size_t fread(
void * ptr, // where the input data will land
size_t size, // the size of one data element
size_t nmemb, // the number of elements to read
FILE * stream // the source from which they're read
);
The first likely point of bafflement is this "element" business.
fread/fwrite don't (necessarily) deal in single bytes, but in
units of (potentially) multi-byte items. To read an array of
forty-two something-or-others, you might use
fread(array, sizeof array[0], 42, stream);
If one something-or-other occupies ten bytes this will read 420
bytes; if it occupies just one byte this reads 42 bytes. The main
thing to keep in mind is that it reads 42 something-or-others of
`sizeof array[0]' bytes each.
Digression: Have you encountered other functions that deal
in "elements" of a specified size instead of directly with bytes?
Sure you have: There's qsort and bsearch, and for that matter calloc:
Each has a pair of arguments that specify an element size and an
element count. But be alert! Notice that qsort et al. describe their
elements the other way around: "count followed by size," whereas
fread/fwrite use "size followed by count." You've heard, perhaps,
of the "cathedral versus bazaar" approaches to system design? C's
library arose from the bazaar, and is occasionally, er, bizarre.
Okay, but what difference does it make? The number of bytes
transferred will be the product of the two arguments, and so will
be the same whichever way you specify them, right? Yes, but then
there's the matter of the value returned by the function: It's the
number of *elements* transferred, not the number of bytes. If you
read 42 10-byte elements or 10 42-byte elements you'll read 420
bytes either way, but one fread call will say "You got 42 elements"
and the other will say "You got 10 elements." Assuming you'll use
the returned value to figure out how many elements your program
should now digest, you'll want to keep size and count straight
lest you wind up reading 10 and trying to process 42, or reading
42 but processing only the first 10!
One problem with reporting the number of "elements" read or
written is that if you get an I/O error or end-of-file in the
middle of an element it's hard to determine exactly how far you
got. For example, if you try to read 42 10-byte elements and fread
says you got 16, you can't tell whether you got exactly 16, or 16
plus four bytes of a 17th and then EOF. A way around this is to use
one as your element size:
size_t bytes = fread(array, 1, 42 * sizeof array[0], stream);
size_t count = bytes / sizeof array[0];
size_t excess = bytes % sizeof array[0];
if (excess != 0) {
// Stopped in mid-element; something's strange.
// Maybe use feof(stream) and/or ferror(stream)
// and/or perror() to diagnose the problem.
...
I hope this helps.