☰

stdbufの完全バッファリングモードを使用しないでください。

tag-icon • tag-icon coreutils
stdbufの完全バッファリングモードを使用しないでください。

私のシステム（最近更新されたArch Linux）では、マンページの「BUGS」セクションにはstdbuf以下が含まれています。

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

おすすめ記事