Did fwrite/fread(3) offer different "multiple items" behavior on different platforms historically?
1
vote
1
answer
227
views
The
fread(3)
and fwrite(3)
have an extra parameter for a variable number of items. So a typical write often has a hardcoded count when all it has is a char buffer to begin with e.g. fwrite(data, len, 1, stdout)
.
What is the point of this parameter? Was this always just a convenience "let the system do the multiplication" thing kind of like calloc(3)
or did some historical operating systems and/or storage devices have special handling for individual items written?
Fueling my curiosity here is that I stumbled across some IBM z/OS documentation for [their fwrite()
](https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxbd00/fwrite.htm) which makes something of a distinction between "record I/O output" and "block I/O output" and talks about how each item could get truncated past a certain length — making me wonder if the item count parameter used to map to, say, separate physical punchcards — or at least maybe data could get written behind the scenes using ASCII "record separator" characters or whatever.
For contrast, the [POSIX fwrite spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fwrite.html) just outright says:
> For each object, size calls shall be made to the fputc()
function, taking the values (in order) from an array of unsigned char exactly overlaying the object.
Which invites the question of why fwrite
didn't just take in a const uint8_t*
buffer and an overall size_t
total length in the first place like write(2)
does.
Asked by natevw
(194 rep)
Oct 23, 2020, 09:14 PM
Last activity: Oct 24, 2020, 04:56 PM
Last activity: Oct 24, 2020, 04:56 PM