Added autoconf instructions to README

Open files in binary mode on systems that have O_BINARY

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

Change th_get_size() macro to return unsigned int

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

.gitignore: ignore binaries and generated files

Added stdlib.h for malloc() in lib/decode.c

Check for NULL before freeing th_pathname

Thanks to Harald Koch for pointing out that AIX 4 and 5 still need this.

decode: avoid using a static buffer in th_get_pathname()

A solution suggested by Chris Frey:
https://lists.feep.net:8080/pipermail/libtar/2013-October/000377.html

Note this can break programs that expect sizeof(TAR) to be fixed.

fix memleaks in libtar sample program

fix memleak on tar_open() failure

fix file descriptor leaks reported by cppcheck

Bug: https://bugzilla.redhat.com/785760

Fix invalid memory de-reference issue

Bug: https://bugzilla.redhat.com/551415

Signed-off-by: Kamil Dudka <kdudka@redhat.com>

Fix missing prototype compiler warnings

Signed-off-by: Kamil Dudka <kdudka@redhat.com>

Added commentary on T_BLOCKSIZE, ssize_t, and int size risks

Thanks to Chris Palmer.

libtar version 1.2.20

Fixed size_t overflow bug, as reported by Timo Warns

Added autoconf checks for __thread compiler support

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.

Fixed thread-safe bug in th_get_pathname()

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.

Added extern "C" protectors to listhash.h

Thanks to Marcin Adamski for the report!

libtar version 1.2.19

Added const to char* function arguments where appropriate

Changed makedev() argument count test from AC_RUN_ to AC_COMPILE_

See https://lists.feep.net:8080/pipermail/libtar/2012-September/000337.html
for the discussion that lead to this change.

Fixed gcc compiler built-in warnings

../compat/snprintf.c:496: warning: conflicting types for built-in function 'pow10'
../compat/snprintf.c:509: warning: conflicting types for built-in function 'round'

Fixed short int / int compiler warnings in va_arg() usage

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

Removed varargs.h and all dependencies on it

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.

libtar version 1.2.18

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.

Added more forgiving CRC checking logic when reading tar files

Tim Kientzle posted the following to the libtar mailing list regarding
the earlier CRC bug:

This exact bug has reappeared many times in different
tar implementations.  Here are two suggestions:

* The standards specify that the checksum is
calculated using unsigned characters.

* The most robust tar readers will compute the
checksum both ways (with unsigned characters and
with signed characters) and accept the header
if either version matches.

https://lists.feep.net:8080/pipermail/libtar/2012-July/000327.html

He gave the following links:

http://pubs.opengroup.org/onlinepubs/9699919799/

"pax" is under "Shell & Utilities" => "Utilities"; here's
a direct link:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
https://github.com/libarchive/libarchive/wiki/ManPageTar5

This commit turns libtar into a "more robust tar reader."

libtar version 1.2.17

Fixed checksum calculation in writing header

Calculation used signed char instead of unsigned char.
Fixed it by calling the same routine used in reading and checking.

libtar version 1.2.16

Fixed build system to allow for out-of-source tree builds

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.

libtar version 1.2.15

Fixed harmless buffer overflow which is caught by FORTIFY on some systems

encode.c takes a shortcut, and updates two struct fields with one
strncpy() call.  This commit splits it into two calls.

libtar version 1.2.14

Fixed truncation check, so 100 char names get GNU extension support when enabled

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.

libtar version 1.2.13

Reduce memory used by libtar when extracting files.

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

Fix memory leak in th_get_pathname

Fix memory leak in th_get_pathname by making the buffer, where prefix
and filename are concatenated, static and returning that instead of a
pointer to a copy of a local buffer.

Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libtar/+bug/41804
https://lists.feep.net:8080/pipermail/libtar/2003-October/000161.html

Escape hyphens that should be minus signs in man pages.

Use libtool to build dynamic library

Changed root Makefile.in to Makefile.am, which make autoreconf workable

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.

Document stupidity of tartype_t in libtar.c.

Bug-Debian: http://bugs.debian.org/309945

(Patch taken from Debian packaging by Chris Frey, and editied slightly
to remove extra header include.)

Applied Marcin Gibula's patch fixing tar_extract_glob()

https://lists.feep.net:8080/pipermail/libtar/2003-September/000160.html

Fixed header warnings

Added datarootdir to Makefile.in's

Removed auto-generated files

Removed m4 includes, and straightened out [] m4 quoting for modern autoconfs

Renamed autoconf/aclocal.m4 to psg.m4 so aclocal isn't so confused

Added autogen.sh script to build a fresh configure

Added autoconf/ as macro dir

Fixed incorrect URL in readme

Patch from Joni Yrjänä
https://lists.feep.net:8080/pipermail/libtar/2006-July/000228.html

libtar-1.2.11 tarball sources, taken from Debian's orig tar

The main site, feep.net, has a broken ftp link, so can't download
tarball from there.