Sstrhsrtj

On my system (a recently updated Arch Linux), the manpage for stdbuf has the following in the "BUGS" section:

On GLIBC platforms, specifying a buffer size, i.e., using fully buffered mode will result in undefined operation.

Apart of being mildly curious why this is the case and what 'undefined operation' means, I'm mostly worried whether or not that means that I should never specify buffer sizes for the command, and whether or not it can explode in my face if I do.

It looks like that's just a left-over from a previous version of stdbuf, and does not correspond to the reality anymore.

In a comment from stdbuf's source code, it says that:

/* 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);

But the actual code goes on and (reluctantly?) allocates the
buffer itself instead of relying on the C library to do it, completely bypassing that problematic behavior.

      if (size > 0)

        {

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

Also this (from the same comment) doesn't seem to be the case anymore:

   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);

No matter what arguments I give to the -i and -o options, it seems to handle them fine. Example:

$ 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, ""..., 143)           = 143

write(1, ""..., 127)          = 127

read(0, ""..., 143)           = 143

write(1, ""..., 127)          = 127

read(0, ""..., 143)           = 143

write(1, ""..., 127)          = 127