There are three places in the library where files are opened. In two
of those places the flag O_BINARY is included if defined. This patch
does the same in the third.
I noticed this because I've been using (a hacked version of) the library
cross-compiled with MinGW on WIN32. I expect Cygwin would also be
affected.
Ron
On systems where size_t is larger than an int (and larger than
unsigned int), then in various places in the library, where
stuff like this happens:
size_t sz = th_get_size(t);
then the int value returned from th_get_size() is sign extended to
some unwieldy amount.
On 64bit systems, this can yield extremely large values.
By fixing this problem in the header, and only for th_get_size(),
we avoid breaking the API of the function call oct_to_int()
(which arguably should return an unsigned int, since the sscanf()
it uses expects to yield an unsigned int). We also fix the library,
which uses th_get_size() internally to assign sizes to size_t.
The drawback is that not all client code that uses th_get_size()
will be fixed, until they recompile, but they will automatically
take advantage of the bugs fixed *inside* the library.
The remaining th_get_*() functions operate on modes and CRC values
and the like, and should be fine, remaining as ints.
Thanks very much to Magnus Holmgren for catching this behaviour.
https://lists.feep.net:8080/pipermail/libtar/2013-October/000365.html
If the compiler does not support __thread or __declspec(thread)
as tested for in autoconf/ax_tls.m4, then libtar is not as threadsafe
as you may expect.
Current libtar breaks in multi-thread app, when reading more then 1
tar simultaneously in different threads, one thread may erroneously
receive the filename for the other thread due to returned static
variable.
This bug was was introduced with the patch with the name "Fix memory
leak in th_get_pathname", which removed strdup() from
th_get_pathname() and made filename static.
../compat/snprintf.c:496: warning: conflicting types for built-in function 'pow10'
../compat/snprintf.c:509: warning: conflicting types for built-in function 'round'
Compiler warned:
../compat/snprintf.c:232: warning: 'short int' is promoted to 'int' when passed through '...'
../compat/snprintf.c:232: note: (so you should pass 'int' not 'short int' to 'va_arg')
../compat/snprintf.c:232: note: if this code is reached, the program will abort
Even configure itself assumes stdarg.h by now in its own tests, at least
on my system, so don't bother with the extra checks anymore, since they
are causing trouble during user compiles.
Note: If your application uses the macro th_crc_ok(), then to gain full
advantage of the changes in this version, you will need to recompile
your application against the new headers. Otherwise, the library is
drop-in replaceable, as usual.
When using configure from a directory other than the top level source
tree, there was trouble compiling the compat/ and listhash/ libraries.
Two minor path fixes changed that.
Reported by Barrie Walker as follows:
I've experienced a problem with 1.2.11 where a name or link is exactly
100 characters.
When not using TAR_GNU name/linknames longer than 99 characters are
simply truncated to 99 characters (+1 for the NUL makes T_NAMELEN (=
100)). Any overflow is lost - fair enough.
Using TAR_GNU, name/linknames longer than 99 characters are still
truncated to 99 characters but the full string is placed in the
gnu_longname/gnu_longlink fields.
However the gnu_longname/gnu_longlink fields are populated only when a
name/linkname would be truncated.
The bug is that the check to see whether there will be truncation
compares the length against T_NAMELEN rather than T_NAMELEN-1.
The fix is simply, in lines 85 and 123 of encode.c, to change T_NAMELEN
to T_NAMELEN-1.
The patch below drastically reduces the amount of memory used by libtar
when extracting files. For each extracted file a 8K struct (MAXPATHLEN is
4096 in Linux) is allocated and inserted in the hashtable for hardlink
mapping. However, in the normal case only a tiny part of those 8K is used.
The patch below calculates the size and allocates no more memory than
needed.
When I unpacked a tar with ~550 files, the memory consumption for the
hashtable went from about 4Mb down to about 200Kb.
/Per
https://lists.feep.net:8080/pipermail/libtar/2003-October/000162.html
Running autoreconf without errors, and using a custom autoconf directory,
means that automake features are used, in order to find that autoconf
directory. This cleans up the root build system to make it less
surprising to maintainers.
