主页 / unix / 问题 / 517064
Accepted
Căcărău
Asked: 2019-05-04 22:42:48 +0800 CST

为什么 hexdump 会尝试读取 EOF？

  • 772

从终端运行时，hexdump不会对行首的单个做出反应^D，就像cat, od,bc等一样，除非还没有输入：

prompt% hexdump -C
<control-D>
prompt% hexdump -C
hello
<control-D><control-D> # a single ^D won't do
00000000  68 65 6c 6c 6f 0a                                 |hello.|
00000006

我可以在 fedora 28 和 debian 9 上重现它。尽管hexdump由bsdmainutilsDebian 提供，但在 bsd 上不会发生这种情况。

这只是一个错误吗？是否有任何其他已知的程序表现出这种行为？

linux io

2 个回答

  1. Best Answer

    感谢@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：

    对于每个对象，应对 fgetc() 函数进行大小调用，并将结果按照读取的顺序存储在恰好覆盖该对象的 unsigned char 数组中。

    关于fgetc：

    如果 stream 指向的输入流的文件结束指示符未设置并且存在下一个字节，则 fgetc() 函数应获取下一个字节

    即使设置了 eof 指示符，glibc 似乎也会尝试“获取下一个字节”。

    事实上，它实际上是GNU C 库中的一个错误，而不存在于 BSD 或 musl C 库中。 它在 2005 年就已为人所知。Ulrich Drepper 在 2007 年关闭了错误报告，但没有修复错误。 在 2012 年进行了讨论，注意到其他 C 库没有也没有这种行为，1999 年的 C 标准对此非常具体，并且 Solaris甚至有一个特殊的机制，当c99被用作编译器而不是cc.

    它终于在 2018 年修复。该修复程序位于 GNU C 库的 2.28 版中。当前 Debian 的“稳定”版本，版本 9，在 GNU C 库的 2.24 版本上，因此这个错误在被报告 14 年后继续表现出来。

    正如 GNU C 库讨论中所指出的，有可能编写的软件需要 GNU C 库的怪癖，而不考虑其他 C 库，例如 musl 或其他平台上的行为。然而，在上述多年来的讨论中，没有发现这样的计划。鉴于一些程序被旧的 GNU C 库破坏，要求用户连续两次发出 EOF 信号，已被确定；hexdump包括这里和patch2018 年的 StackOverflow 上的其他内容。

    • 3

  2. strace 的输出

    …
read(0, "hello\n", 1024)                = 6
read(0, "", 1024)                       = 0
read(0, "hello\n", 1024)                = 6
read(0, "", 1024)                       = 0
read(0, "", 1024)                       = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 11), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8dd4cef000
write(1, "0000000   h   e   l   l   o  \\n "..., 72) = 72
write(1, "000000c\n", 8)                = 8
exit_group(0)                           = ?
+++ exited with 0 +++

    在这里，我做了 hello «ctrl-d» hello «ctrl-d» «ctrl-d» （第二个 hello 在日志输出中被截断）。所以看起来它是这样编程的。

    运行 strace

    • 打开两个终端
    • 在第一类ll /proc/self/fd/1
    • 在第二种类型strace hexdump -C 2>/dev/pts/«number-at-end-of-output-of-previous-command»
    • 0

相关问题