☰

我不应该使用 stdbuf 的完全缓冲模式吗？

tag-icon • tag-icon coreutils
我不应该使用 stdbuf 的完全缓冲模式吗？

在我的系统（最近更新的 Arch Linux）上，联机帮助页的stdbuf“BUGS”部分包含以下内容：

在GLIBC平台上，指定缓冲区大小，即使用完全缓冲模式将导致未定义的操作。

除了有点好奇为什么会出现这种情况以及“未定义操作”的含义之外，我最担心的是这是否意味着我不应该为命令指定缓冲区大小，以及它是否会在我面前爆炸：我愿意。

答案1

看起来这只是以前版本的遗留物stdbuf，与现实不再相符。

在一个评论从stdbuf的源代码来看，它说：

/* Note currently for glibc (2.3.5) the following call does not change
   the buffer size, and more problematically does not give any indication
   that the new size request was ignored:
       setvbuf (stdout, (char*)NULL, _IOFBF, 8192);

但实际的代码会继续（不情愿地？）分配缓冲区本身，而不是依赖 C 库来完成，完全绕过了有问题的行为。

      if (size > 0)
        {
          if (!(buf = malloc (size))) /* will be freed by fclose()  */

而且（来自同一条评论）似乎不再是这种情况了：

   Another issue is that on glibc-2.7 the following doesn't buffer
   the first write if it's greater than 1 byte.
       setvbuf(stdout,buf,_IOFBF,127);

无论我对-i和-o选项给出什么论据，它似乎都能很好地处理它们。例子：

$ echo 'int main(){ int c; while((c=getchar()) != EOF) putchar(c); }' | cc -include stdio.h -x c - -o slowcat
$ strace -s5 -e trace=read,write stdbuf -i143 -o127 2>&1 ./slowcat </dev/zero >/dev/null | awk '/ELF/{next}1;++n>5{exit}'
read(0, "\0\0\0\0\0"..., 143)           = 143
write(1, "\0\0\0\0\0"..., 127)          = 127
read(0, "\0\0\0\0\0"..., 143)           = 143
write(1, "\0\0\0\0\0"..., 127)          = 127
read(0, "\0\0\0\0\0"..., 143)           = 143
write(1, "\0\0\0\0\0"..., 127)          = 127

相关内容