История изменений

Будет ли программа работать, если файлом будет /dev/stdin

Не будет.

Если нет, то не проще ли было вместо всех этих «ехал buflen через bufsize» просто mmap’нуть файл?

Проще, но mmap медленнее при некоторых условиях (прога не может сообщить ядру что его надо read-ahead). Конкретно тут не измерял.

Не знаю, правда, какие есть ограничения на размер файла при mmap

А, ну и да, mmap нельзя больше чем размер юзерспейсного адресного пространства (на 32 битах - около 3гб вроде), так что у меня бы оно тупо не запустилось даже с разделом на 150гб. Хотя я об этом не подумал. Вот был бы сюрприз если б забил на предыдущий аспект.

Ещё такой вопрос: для чего и как работает эта проверка?

Это проверка на переполнение.

Насколько я знаю, длина аргументов ограничена размером стека и обычно составляет 1/4 от него.

Это всё может быть, но любая арифметическая операция должна проверяться на переполнение, если прям строго-строго перед ней нет гарантий что переполнения не случится. Иначе при последующих изменениях обстоятельств или рефакторинге переполнение имеет шанс таки случиться, совершенно молча. Вот тут например строка берётся из аргументов, а вдруг потом она будет читаться из файла? Файлочиталка, очевидно, всё равно ограничит её в size_t, но вот прочитать SIZE_MAX/2 она уже вполне сможет. При этом о том, что при замене способа получения строки надо ещё и аллокацию буфера править, можно и не помнить.

Будет ли программа работать, если файлом будет /dev/stdin

Не будет.

Если нет, то не проще ли было вместо всех этих «ехал buflen через bufsize» просто mmap’нуть файл?

Проще, но mmap медленнее при некоторых условиях (прога не может сообщить ядру что его надо read-ahead). Конкретно тут не измерял.

Не знаю, правда, какие есть ограничения на размер файла при mmap

А, ну и да, mmap нельзя больше чем размер юзерспейсного адресного пространства (на 32 битах - около 3гб вроде), так что у меня бы оно тупо не запустилось даже с разделом на 150гб. Хотя я об этом не подумал. Вот был бы сюрприз если б забил на предыдущий аспект.

Ещё такой вопрос: для чего и как работает эта проверка?

Это проверка не переполнение.

Насколько я знаю, длина аргументов ограничена размером стека и обычно составляет 1/4 от него.

Это всё может быть, но любая арифметическая операция должна проверяться на переполнение, если прям строго-строго перед ней нет гарантий что переполнения не случится. Иначе при последующих изменениях обстоятельств или рефакторинге переполнение имеет шанс таки случиться, совершенно молча. Вот тут например строка берётся из аргументов, а вдруг потом она будет читаться из файла? Файлочиталка, очевидно, всё равно ограничит её в size_t, но вот прочитать SIZE_MAX/2 она уже вполне сможет. При этом о том, что при замене способа получения строки надо ещё и аллокацию буфера править, можно и не помнить.

Будет ли программа работать, если файлом будет /dev/stdin

Не будет.

Если нет, то не проще ли было вместо всех этих «ехал buflen через bufsize» просто mmap’нуть файл?

Проще, но mmap медленнее при некоторых условиях (прога не может сообщить ядру что его надо read-ahead). Конкретно тут не измерял.

Не знаю, правда, какие есть ограничения на размер файла при mmap

А, ну и да, mmap нельзя больше чем размер юзерспейсного адресного пространства (на 32 битах - около 3гб вроде), так что у меня бы оно тупо не запустилось даже с разделом на 150гб. Хотя я об этом не подумал. Вот был бы сюрприз если б забил на предыдущий аспект.

Ещё такой вопрос: для чего и как работает эта проверка?

Это проверка не переполнение.

Насколько я знаю, длина аргументов ограничена размером стека и обычно составляет 1/4 от него.

Это всё может быть, но любая арифметическая операция должна проверяться на переполнение, если прям строго-строго перед ней нет гарантий что переполнения не случится. Иначе при последующих изменениях обстоятельств или рефакторинге переполнение имеет шанс таки случиться, совершенно молча.