Благодаря @JdeBP за подсказку , я смог создать небольшой тестовый пример, который делает то же самое, что и hexdump:

#include <stdio.h>

int main(void){
        char buf[64]; size_t r;
        for(;;){
                printf("eof=%d, error=%d\n", feof(stdin), ferror(stdin));
                r = fread(buf, 1, sizeof buf, stdin);
                printf("read %zd bytes, eof=%d, error=%d\n",
                        r, feof(stdin), ferror(stdin));
                if(!r) return 0;
        }
}

При запуске в системе на основе glibc (типичный рабочий стол Linux ).

prompt$./fread-test
eof=0, error=0
<control-D>
read 0 bytes, eof=1, error=0

prompt$./fread-test
eof=0, error=0
hello
<control-D>
read 6 bytes, eof=1, error=0
eof=1, error=0
<control-D>
read 0 bytes, eof=1, error=0

При запуске на bsd, solaris, busybox (uclibc ), android и т. д.:

prompt$./fread-test
eof=0, error=0
hello
<control-D>
read 6 bytes, eof=1, error=0
eof=1, error=0
read 0 bytes, eof=1, error=0

Основываясь на моей неумелой интерпретации стандарта, это похоже на ошибку в glibc (библиотеки GNU C ).

Оfread:

For each object, size calls shall be made to the fgetc() function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object.

Оfgetc:

If the end-of-file indicator for the input stream pointed to by stream is not set and a next byte is present, the fgetc() function shall obtain the next byte

Кажется, что glibc попытается "получить следующий байт", даже если установлен индикатор eof.

Действительно, это на самом деле ошибка в библиотеке GNU C, которой нет в библиотеках BSD или musl C. Об этом стало известно в 2005 году . Ульрих Дреппер закрыл отчет об ошибке, не исправив ошибку в 2007 году. Это обсуждалось в 2012 году , где было отмечено, что другие библиотеки C не имеют и не имеют такого поведения, что стандарт C 1999 года довольно специфичен. об этом, и что в Solaris даже есть специальный механизм для этого, который вызывается, когда c99используется в качестве компилятора вместо cc.

Это было окончательно исправлено в 2018 году . Исправление находится в версии 2.28 библиотеки GNU C. Текущая «стабильная» версия Debian, версия 9, относится к версии 2.24 библиотеки GNU C , и поэтому эта ошибка продолжает проявляться спустя 14 лет после того, как о ней сообщили.

Как отмечалось в обсуждениях библиотеки GNU C, существует возможность того, что программное обеспечение, написанное так, требует особенностей библиотеки GNU C, независимо от других библиотек C, таких как musl, или поведения на других платформы. Однако в вышеупомянутых дискуссиях за эти годы такой программы выявлено не было. Принимая во внимание, что было обнаружено несколько программ, которые сломаны старой библиотекой GNU C и требуют от пользователей дважды сигнализировать EOF;в том числе hexdumpздесь и patchна StackOverflow еще в 2018 году .