Is this the reason why fread/fwrite has 2 `size_t` arguments?

Question

It just came to me that, the C standard I/O functions fread and fwrite are having 2 size_t arguments because of I guess possibly, that on some systems, there may be more memory of which whose size can be represented in a single size_t type.

With 2 size_ts, 1 for element size, another for elements count, caller will be able to read/write more data than can be measured with a single size_t.

I find it reasonable with some ancient x86 processors with "near" addressing.

Is this thinking right? What's the real history here?

Answer 1

AT&T's documentation for fread and fwrite that pre-dates size_t is quoted below. But first, to answer the title question:

1. Both functions are designed for objects, not characters. This is evidenced by the return value being a count of the objects read or written, not the number of characters.

2. Each function may read/write fewer objects than requested. Well-written code will make another attempt to read/write the remaining objects. (This is also true of the character I/O.) The code to re-attempt reading/writing is a lot simpler if you need to only keep track of the number of objects, instead of the number of characters (which then requires dealing with alignment issues).

3. The original implementation used the int type for both the number of objects and the size of the objects. When size_t and other _t types were introduced, those two arguments needed to retain the same type, to avoid breaking existing source code and compiled libraries.

It has very little to do with the size of memory.

---

The use of size_t and other _t data types did not appear until K&Rv2. Before then, the arguments to standard library functions were of int and long types. For example, The C Programmer's Handbook, AT&T Bell Laboratories, February 1984, p. 50 states (C++ style comments are my addition):

BLOCK I/O

Manual Page -- The functions in this section are on the fread(3S) manual page.

fread -- Read specified number of bytes (characters) from stream.

• Synopsis:

    int fread (ptr, size, nitems, stream)
    char *ptr;
    int size, nitems;    // <--- THEY WERE BOTH INT
    FILE *stream;

fwrite -- Write specified number of bytes to stream.

• Synopsis:

    int fwrite (ptr, size, nitems, stream)
    char *ptr;
    int size, nitems;    // <--- THEY WERE BOTH INT
    FILE *stream;

size_t was established by the time the second edition of The C Programming Language, Kernighan and Ritchie, 1988 was written. The functions in question are described on p. 247:

B1.5 Direct Input and Output Functions

size_t fread(void *ptr, size_t size, size_t nobj, FILE *stream)

fread reads from stream into the array ptr at most nobj objects of size size. fread returns the number of objects read; this may be less than the number requested. feof and ferror must be used to determine status.

size_t fwrite(const void *ptr, size_t size, size_t nobj, FILE *stream)

fwrite writes, from the array ptr, nobj objects of size size on stream. It returns the number of objects written, which is less than nobj on error.

Answer 2

The point of fread/fwrite is to write N elements, each of size S bytes. The API is not a simple 'write this number of bytes' interface.

Thus, for example:

struct S { int a, b; float c; };
struct S stuff[92];
fwrite(stuff, sizeof (struct S), 92, stream);

(I would not write '92' in real code, but I want the simple formulation in this example)

Thus it has two size values because it needs them to express the intended operation.

(I don't much like the API, but there it is)

It is not that this is arranged just in case one size_t value can't handle the overall size to read/write, because size_t is by definition large enough to hold the size of the largest possible object (it’s defined as “the unsigned integral type of the result of the sizeof operator”) — and anything fread/fwrite can handle is a single contiguous object. To put it another way, given my above code fragement.

 size_t sz = sizeof stuff;

is guaranteed to be valid.

---

In the Rationale for ANSI-X3.159-1989 (the document accompanying the standard that explains why decisions were made). it says

size_t is the appropriate type both for an object size and for an array bound, so this is the type of size and nelem.

Now, they were standardizing an existing function, not inventing it, and this just says why the type is now size_t rather than, say, int. But it's clear they were thinking in terms of reading and writing an array.

Answer 3

For STDIO files with no buffering, referring to "raw" devices, like tapes, it is important how the write system calls are issued, because each write system call results in a tape block of the specified size (and to read a raw block, a read system call of size no less than the block size is required).

The fwrite/fread API appears to facilitate writing and reading multiple blocks of the specified size, but various versions of fwrite, including UNIX V7 ignore that distinction.

Could be a conceived but never finalized feature.