Каково обоснование того, что fread / fwrite принимает размер и учитывается в качестве аргументов?

Это основано на том, как реализован fread.

В единой спецификации UNIX говорится

Для каждого объекта должны быть выполнены вызовы размера функции fgetc (), а результаты будут сохранены в порядке чтения в массиве беззнаковых символов, точно перекрывающем объект.

fgetc также содержит это примечание:

Поскольку fgetc () работает с байтами, чтение символа, состоящего из нескольких байтов (или «многобайтового символа»), может потребовать нескольких вызовов fgetc ().

Конечно, это предшествует причудливым кодировкам символов с переменными байтами, таким как UTF-8.

SUS отмечает, что это фактически взято из документов ISO C.

Разница между fread(buf, 1000, 1, stream) и fread(buf, 1, 1000, stream) заключается в том, что в первом случае вы получаете только один фрагмент размером 1000 байт или ничего, если файл меньше, а во втором случае вы получаете все в файле размером менее 1000 байт.

Это чистые предположения, однако в те времена (некоторые все еще существуют) многие файловые системы не были простыми потоками байтов на жестком диске.

Многие файловые системы основаны на записях, поэтому для эффективного удовлетворения таких файловых систем вам нужно будет указать количество элементов («записей»), что позволит fwrite / fread работать с хранилищем как с записями, а не только с потоками байтов.

Вот, позвольте мне исправить эти функции:

size_t fread_buf( void* ptr, size_t size, FILE* stream)
{
    return fread( ptr, 1, size, stream);
}


size_t fwrite_buf( void const* ptr, size_t size, FILE* stream)
{
    return fwrite( ptr, 1, size, stream);
}

Что касается обоснования параметров _2 _ / _ 3_, я давно потерял свою копию K&R, поэтому могу только догадываться. Я думаю, что вероятный ответ заключается в том, что Керниган и Ричи могли просто подумать, что выполнение двоичного ввода-вывода будет наиболее естественно выполняться на массивах объектов. Кроме того, они могли подумать, что блочный ввод-вывод будет быстрее / проще реализовать или что-то еще на некоторых архитектурах.

Несмотря на то, что стандарт C определяет, что fread() и fwrite() должны быть реализованы в терминах fgetc() и fputc(), помните, что стандарт появился задолго после того, как C был определен K&R, и что вещи, указанные в стандарте, могли не входить в первоначальные идеи дизайнеров. Возможно даже, что вещи, сказанные в «Языке программирования C» K&R, могут быть не такими, как когда язык только разрабатывался.

Наконец, вот что П.Дж. Плогер говорит о fread() в "Стандартной библиотеке C":

Если size (второй) аргумент больше единицы, вы не можете определить, считала ли функция до size - 1 дополнительных символов сверх того, о чем она сообщает. Как правило, лучше вызывать функцию как fread(buf, 1, size * n, stream); вместо fread(buf, size, n, stream);

По сути, он говорит, что интерфейс fread() сломан. Что касается fwrite(), он отмечает, что «ошибки записи обычно редки, поэтому это не является серьезным недостатком» - с утверждением, с которым я бы не согласился.

Вероятно, это восходит к тому, как был реализован файловый ввод-вывод. (в те времена) Возможно, было бы быстрее записывать / читать файлы блоками, чем записывать все сразу.

Наличие отдельных аргументов для размера и количества может быть выгодным для реализации, которая может избежать чтения каких-либо частичных записей. Если бы кто-то использовал однобайтовые чтения из чего-то вроде конвейера, даже если бы он использовал данные фиксированного формата, нужно было бы допустить возможность разделения записи на два чтения. Если бы вместо этого можно было запросить, например, неблокирующее чтение до 40 записей по 10 байтов каждая, когда доступно 293 байта, и получение системой 290 байтов (29 целых записей), оставляя 3 байта готовыми для следующего чтения, что было бы намного удобнее.

Я не знаю, в какой степени реализации fread могут обрабатывать такую ​​семантику, но они, безусловно, могут быть полезны в реализациях, которые могут обещать их поддерживать.