bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU tar 1.11.2 to 1.13.5 on AIX 3.2.5


From: Tilo Stroh
Subject: GNU tar 1.11.2 to 1.13.5 on AIX 3.2.5
Date: Mon, 25 Sep 2000 19:20:07 +0200 (DFT)

Dear GNU-TAR people,

when un-TAR-ing an archive, which contains file names whose 8th bits are
not zero throughout, with GNU-TAR normally compiled under AIX (3.2.5) with
whatever compiler (cc[xlccmp.obj 01.03.0000.0043], gcc 2.8.1) while using
various "configure" options, the process suddenly interrupts with an
"gtar: Skipping to next file header..." error message. Searching through
the sources for the error message leads to the file "list.c", where before
the routine "read_header" the following comment shows up [actual code from
"tar-1.13.5.tar.gz" in "tar-1.13.5-1.src.rpm"]:

/* FIXME: The signed checksum computation is broken on machines where char's
   are unsigned.  It's uneasy to handle all cases correctly...  */

Characters are unsigned under AIX 3.2.5 by default. One can of course use
signed characters for the compilers with options "-qchars=signed" for "cc"
and "-fsigned-char" for "gcc", which I actually did not try, but one can
also try to circumvent this problem by writing conditional code whether
signed or unsigned characters are used at compile time. I have (as a trial)
changed the code of "list.c" by defining a "cpp" macro named
"CHAR_IS_UNSIGNED" and have added the definition "#define CHAR_IS_UNSIGNED 1"
in "config.h" for my machine:

==============================================================================
$ diff list.c list.c.sav
345,348d344
< #ifdef CHAR_IS_UNSIGNED
<         unsigned_sum += *p;
<         signed_sum += (signed char)*p++;
< #else
351d346
< #endif
358,361d352
< #ifdef CHAR_IS_UNSIGNED
<         unsigned_sum -= header->header.chksum[i];
<         signed_sum -= (signed char)header->header.chksum[i];
< #else
364d354
< #endif
==============================================================================

With these changes the "tar" program seems to work, however, I cannot judge
whether the one or the other suggestion completely solves the problem or
whether there are more elaborate solutions or, e.g., the name of the "cpp"
variable fits into the naming convention. It would probably be a good idea
to incorporate one of these or different thoughts into the "configure" script
to automatically handle system or compiler defaults.

Sincerely,
T. Stroh




reply via email to

[Prev in Thread] Current Thread [Next in Thread]