[dev] Miscellaneous sbase issues

From: Michael Forney <mforney_AT_mforney.org>
Date: Sun, 26 Apr 2015 18:24:18 -0700

Hi suckless,

I came across some issues in sbase whose solution wasn't immediately
apparent:

printf
------
Ignores flag characters '#', '0', '-', ' ', and '+', but is labeled as
POSIX compliant and complete, so this is presumably unintentional.

"git am" breaks without this functionality.

tar

---
Since fb1595a69c091a6f6a9303b1fab19360b876d114, tar calls remove(3) on
directories before extracting them. I'm not sure that it is reasonable
for tar to do this because users may want to re-extract archives, or
extract archives on top a directory structure that already exists.
Additionally, it is fairly common to find tar archives containing the
"." directory (possibly with a trailing '/'), which were constructed
using "tar -cf foo.tar .".
cat, tee
--------
These utilities read from stdin using fread(3) into a buffer of size
BUFSIZ. However, fread will read until it fills up the entire buffer (or
hits EOF) before returning, causing noticeable delay when the input
comes from other programs or scripts.
To demonstrate this problem, compare the output of these commands:
  for i in $(seq 500) ; do printf 0123456789abcdef ; sleep 0.005 ; done
  for i in $(seq 500) ; do printf 0123456789abcdef ; sleep 0.005 ; done | cat
  for i in $(seq 500) ; do printf 0123456789abcdef ; sleep 0.005 ; done | tee
I considered fixing this by making the concat function take an fd
instead and make a single call to read(2), but this causes problems for
sponge, which uses a FILE * obtained from tmpfile(3) as both output and
input for concat. We could also use mkstemp(3) to return a file
descriptor, and use a FILE * from fdopen for writing, and the file
descriptor for reading, but this seems unclean to me.
Another option would be to use fgetc and fputc for the concat
implementation, and let libc take care of the buffering. I'm not sure if
this has any performance implications.
Thanks everyone for their work on sbase! It really has come a long way
in the last 6 months.

Received on Mon Apr 27 2015 - 03:24:18 CEST