🚀 go-pugleaf

This reports an `hurry' installation of GNU tar 1.11.1 on a recent
ESIX system (System V R4 flavor, I do not know which version), while
passing nearby.  I'm away now.  This slightly fuzzy report is repeated
from hastily written notes.  The problems were real, however.

* I needed to put -Dconst= to get it to compile, as a kludge.
Somewhere, some system include files define prototypes, using const.
Then, a tar include file defines const as empty.  Finally, further
system files are included which have consistent redeclarations of
prototypes, but since const is now empty, these redeclarations produce
compilation errors.  const should rather not be defined to empty for
this system.

* In Makefile.in, ALLOCA = @ALLOCA@ is missing, as well as $(ALLOCA)
in the load object list.

* msg("cound only write %d of %d bytes to file %s\n", ...) appears two
times in extract.c.  I think that in both cases, the argument list is
incorrect.  The first time, written and check are reversed.  The
second time, `totalsize - *sizeleft' cannot be good, the value
returned by the write call should be used somewhere.  The user problem
triggering the diagnostic was a too small ulimit.

* `tar tfvz FILE.tar.Z' (and `tar x...' too) sometimes (maybe for 3
out of 15 archive files) produces, after having processed many files,
almost all, maybe all, the quite unexpected diagnostic:

	write error onstdout: I/O error

There was no space between `on' and `stdout'.  For all cases, stdout
was not redirected.  The problem was repeatable while I was there on a
file by file basis, that is, when a file was getting tar to fail with
this diagnostic, the file was always getting tar to fail.

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!