Fix undefined left shift with signed ints

Caught by Clang's -fsanitize=shift.  A small unsigned int was promoted,
according to C's regular promotion rules, to a signed int, it was then
left shifted.  This sometimes pushed a 1 into the sign bit, which is
undefined behaviour.  Fix by using unsigned temporaries.
"now - 2 hours" should be the same as "2 hours ago"
This was broken by a mis-parsing of the "2 hours" phrase.
Fix cmake test builds when building as a sub-project
Run code coverage on your local machine

This change introduces a new make target called "coverage" it will
compile your code using special GCC flags, run the tests, and then
generate a nice HTML output.

This new make target will only be available if you build using GCC in
Debug mode.

To build the code coverage and open it in your browser do this:

    mkdir debug
    cd debug
    cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON ..
    make -j20
    make coverage
    xdg-open coverage/index.html
Simplify passing of linker flags to try_compile calls

In commit d7bd02b6 (Modify CHECK_C_SOURCE_* checks to fix builds using
Visual Studio 12, 2013-02-01), commit e3d14342 (Set use of /SAFESEH linker
flag for all LIBARCHIVE_CHECK_C_SOURCE_* checks, 2013-02-01), and commit
58dc42aa (Fix checks for crypto algorithms in Visual Studio builds,
2013-02-01) we introduced and used custom copies of the CMake
CheckCSource(Compiles|Runs) modules in order to pass linker flags to
try_compile calls.  CMake has an issue tracker entry about passing
CMAKE_*_LINKER_FLAGS to try_compile calls:

  http://www.cmake.org/Bug/view.php?id=14066

Discussion there suggests a much simpler workaround: pass the flags
through the LDFLAGS environment variable.  Remove our custom check
macros and use the simpler workaround instead.
include linux/types.h on CentOS 5 in test_sparse_basic.c

Was getting this error:

In file included from ....../libarchive-3.1.2/libarchive/test/test_sparse_basic.c:44:
/usr/include/linux/fiemap.h:15: error: expected specifier-qualifier-list before ‘__u64’
/usr/include/linux/fiemap.h:26: error: expected specifier-qualifier-list before ‘__u64’


From https://groups.google.com/forum/#!msg/libarchive-discuss/691PHz5ENOc/4OzXBevG75AJ I see that the <linux/types.h> file is not included.

This fixed the problem for me on CentOS 5.8.
It was not visible as an issue on CentOS 6.3 or Ubuntu 10 or 12.

This change did not appear to break those already functioning platforms.
Merge branch 'master' of github.com:libarchive/libarchive
Some more test cases around the "2 hours ago" concept.
Fix chown line in shardump format

Currently the chown line is written with no space before entry name.
Added all Zip compression names from 6.3.3 format

I've added all the compression names and IDs from the ".ZIP File Format
Specification" version 6.3.3  that can be found in section "4.4.5
compression method" of this document:

http://www.pkware.com/documents/casestudies/APPNOTE.TXT
Simplified and fixed Zip compression method array

I've removed the description string element from the compression_method
struct and fixed some spelling errors (imb -> ibm).
Removed compression_method struct type

Since it was only used in one place, I've remove the struct type.
Show third party library versions in version string

Add a utility function, archive_version_details, to return a string
containing the libarchive version as well as the versions of third party
libraries such as zlib, bz2lib and liblzma.  Use this function for
bsdtar --version and bsdcpio --version.

http://code.google.com/p/libarchive/issues/detail?id=118
Use correct variable types for ASCII Windows functions.

There are both an ASCII and an Unicode variant for most of the Win32 API.
Fix some inconsistent uses.
Detect encrypted archive entries (ZIP, RAR, 7Zip)

With this change you can detect if an archive entry is encrypted. The
archive formats covered with this change are: ZIP, RAR, and 7zip. Other
formats can be added quite simply by looking at the already supported
formats. For all the already supported formats we have tests that check
if:

	* an archive entries's data is encryped (data test)
	* an archive entries's metadata is encrypted (header test)
	* one file is encrypted while another is not (partially test)

These new functions are introduced.

int archive_read_format_capabilities(struct archive*)

	Returns a bitmask of capabilities that are supported by the archive
	format reader. If the reader has no special capabilities,
	ARCHIVE_READ_FORMAT_CAPS_NONE is returned; otherwise 0 is returned.

	You can call this function even before reading the first header from
	an archive.

	Return Values:
	* ARCHIVE_READ_FORMAT_CAPS_ENCRYPT_DATA
		The reader supports detection of encrypted data.
	* ARCHIVE_READ_FORMAT_CAPS_ENCRYPT_METADATA
		The reader supports detection of encrypted metadata (e.g.
		filename, modification time, size, etc.)
	* ARCHIVE_READ_FORMAT_CAPS_NONE
		None of the above capabilities. If this value is returned, this
		doesn't mean that the format itself doesn't support any type of
		encryption it simply means that the reader is not capable of
		detecting it.

int archive_read_has_encrypted_entries(struct archive *)

	Returns "true" (non-zero) if the archive contains at least one
	encrypted entry, no matter which encryption type (data or metadata)
	is used; otherwise 0 is returned.

	You should only call this function after reading the first header
	from an archive.

	NOTE: I'm not sure that this function will stay in for long.

int archive_entry_is_data_encrypted(struct archive_entry*)

	Returns "true" (non-zero) if the archive entry's data is encrypted;
	otherwise 0 is returned. You can call this function after calling
	archive_read_next_header().

int archive_entry_is_metadata_encrypted(struct archive_entry*)

	Returns "true" (non-zero) if the archive entry's metadata is
	encrypted; otherwise 0 is returned. You can call this function after
	calling archive_read_next_header().

int archive_entry_is_encrypted(struct archive_entry*)

	Returns "true" (non-zero) if either the archive entry's data and/or
	it's metadata is encrypted; otherwise 0 is returned. You can call
	this function after calling archive_read_next_header().

If you use archive_read_format_capabilities() in combination with one of
the archive_entry_is_[data|metadata]_encrypted() functions, you can be
sure that you've encountered an encrypted entry. This allows you to
react differently depending on libarchive's return codes. For instance,
you might want to skip encrypted files from being extracted until
decryption support has been implemented.

Here's how I generated the 7zip test files:
-------------------------------------------

With header encrpytion (-mhe=on):

    $ rm -f test_read_format_7zip_encryption_header.7z
    $ echo "foo" > bar.txt && 7z a -mhe=on -p12345678 \
    test_read_format_7zip_encryption_header.7z bar.txt

    $ uuencode test_read_format_7zip_encryption_header.7z \
    test_read_format_7zip_encryption_header.7z > \
    test_read_format_7zip_encryption_header.7z.uu

Without header encrpytion (-mhe=off):

    $ rm -f test_read_format_7zip_encryption.7z
    $ echo "foo" > bar.txt && 7z a -mhe=off -p12345678 \
    test_read_format_7zip_encryption.7z bar.txt

    $ uuencode test_read_format_7zip_encryption.7z \
    test_read_format_7zip_encryption.7z > \
    test_read_format_7zip_encryption.7z.uu

Partially encrypted archive:

	$ rm -f test_read_format_7zip_encryption_partially.7z
	$ echo "foo" > bar_unencrypted.txt && 7z a \
	test_read_format_7zip_encryption_partially.7z bar_unencrypted.txt
	$ echo "foo" > bar_encrypted.txt && 7z a -mhe=off -p12345678 \
	test_read_format_7zip_encryption_partially.7z bar_encrypted.txt

	$ uuencode test_read_format_7zip_encryption_partially.7z \
	test_read_format_7zip_encryption_partially.7z > \
	test_read_format_7zip_encryption_partially.7z.uu

Here's how I generated the RAR test files:
------------------------------------------

These are the files we can will add to the archives:

    echo "data of foo.txt" > foo.txt
    echo "data of bar.txt" > bar.txt

 With header encrpytion (-hp):

    rm -f test_read_format_rar_encryption_header.rar
    rar a -hp12345678 test_read_format_rar_encryption_header.rar \
    foo.txt bar.txt

    uuencode test_read_format_rar_encryption_header.rar \
    test_read_format_rar_encryption_header.rar > \
    test_read_format_rar_encryption_header.rar.uu

Without header encrpytion (-p):

    rm -f test_read_format_rar_encryption_data.rar
    rar a -p12345678 test_read_format_rar_encryption_data.rar \
    foo.txt bar.txt

    uuencode test_read_format_rar_encryption_data.rar \
    test_read_format_rar_encryption_data.rar > \
    test_read_format_rar_encryption_data.rar.uu

Partially encrypted archive (-p on "foo.txt" and no password on "bar.txt"):

    rm -f test_read_format_rar_encryption_partially.rar
    rar a -p12345678 test_read_format_rar_encryption_partially.rar foo.txt
    rar a test_read_format_rar_encryption_partially.rar bar.txt

    uuencode test_read_format_rar_encryption_partially.rar \
    test_read_format_rar_encryption_partially.rar > \
    test_read_format_rar_encryption_partially.rar.uu

Here's how I generated the ZIP test files:
------------------------------------------

This is how I've created the test files:

These are the files we will add to the archives:
  On Windows:
    echo "data of foo.txt" > foo.txt
    echo "data of bar.txt" > bar.txt

For the creation of the Zip archives I've used the
PKZIP Command Line Add-On available from here:

http://comm.pkware.com/pkzip-cli-download.html

With header (aka central directory) encrpytion (-cd):

  On Windows:
    del /F test_read_format_zip_encryption_header.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 -cd test_read_format_zip_encryption_header.zip foo.txt bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_header.zip \
    test_read_format_zip_encryption_header.zip > \
    test_read_format_zip_encryption_header.zip.uu

Without header encrpytion:

  On Windows:
    del /F test_read_format_zip_encryption_data.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 test_read_format_zip_encryption_data.zip foo.txt bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_data.zip \
    test_read_format_zip_encryption_data.zip > \
    test_read_format_zip_encryption_data.zip.uu

Partially encrypted archive ("foo.txt" is encrypted and "bar.txt" is not):

  On Windows:
    del /F test_read_format_zip_encryption_partially.zip
    pkzipc.exe -add -cryptalgorithm=AES,256 -passphrase=12345678 test_read_format_zip_encryption_partially.zip foo.txt
    pkzipc.exe -add test_read_format_zip_encryption_partially.zip bar.txt

  On Linux:
    uuencode test_read_format_zip_encryption_partially.zip \
    test_read_format_zip_encryption_partially.zip > \
    test_read_format_zip_encryption_partially.zip.uu
Store encryption info in single char of entry

Instead of two chars the information about encryption is now stored in
one single char inside of an archive_entry struct.
Merge branch 'no-signed-shift'
Merge branch 'simplify-link-flags'
Avoid struct init with variable

Compilers such as Borland and MIPSpro do not like struct initialization
with variables.  Initialize using assignment instead.
Better archive_read_has_encrypted_entries function

These are the possible return values:
=====================================

ARCHIVE_READ_FORMAT_ENCRYPTION_UNSUPPORTED (-2):
------------------------------------------------
This is the default return value for reader that don't support
encrpytion detection at all. When this value is returned you can be sure
that it will always be returned even on later calls to
archive_read_has_encrypted_entries.

ARCHIVE_READ_FORMAT_ENCRYPTION_DONT_KNOW (-1):
----------------------------------------------
This is the default return value for readers that support encryption. It
means that the reader is not yet ready (e.g. not enough data was read so
far) to say that there are encrypted entries in the archive. Over time
as more data was consumed by a reader this value might change to 0 or 1.

0:
--
No encrypted entries were found yet (maybe there will be one when
reading the next header). When 0 is returned, it might be that on a
later call 1 will be returned.

1:
--
At least one encrypted entry was found. Once 1 is returned. It will
always be returned even if the another entry is not encrypted.

NOTE:
=====
If the metadata/header of an archive is also encrypted, you
cannot rely on the number of encrypted entries. That is why this
function does not return the number of encrypted entries but
just 1 to show that there are some. Also, two distinct readers might
detect the number of entries and their encryption status at different
times. If one reader can say how many files are encrypted after reading
the first header another reader might need more data. In the end the
number of encrypted entries might be the same in two archives while the
appropriate readers output different results at different points in
time. This is more confusing than helpful.