Seems that in addition on Windows and DOS, also OpenBSD
lacks support for %'d style printf() format strings.
So far that is the only modern POSIX-like system I know
with this problem, but after this hack, the thousand
separator shouldn't be a problem on any system.
Maybe testing if a format string like %'d produces
reasonable output is invoking undefined behavior on some
systems, but so far all the problematic systems I've tried
just print the raw format string (e.g. %'d prints 'd).
Maybe Autoconf test would have been better, but this
hack works also for cross-compilation, and avoids
recompilation in case the system libc starts to support
the thousand separator.
Added lzma_nothrow for every function. It adds
throw() when the header is used in C++ code.
Some lzma_attrs were added or removed.
Lots of comments were improved.
Some programs will by default be linked against static
liblzma and some against shared liblzma. --enable-dynamic
now allows overriding the default to both directions
(all dynamic or all static) even when building both
shared and static liblzma.
This is quite messy compared to how simple thing it is supposed
to be. The complexity is mostly due to Windows support.
lzmainfo now links against static liblzma. In contrast
to other command line tools in XZ Utils, linking lzmainfo
against static liblzma by default is dumb. This will be
fixed once I have fixed some related issues in configure.ac.
Attempts to compare two compressed files result in no output and
exit status 2.
Instead of going to standard output, ‘diff’ output is being
captured in the xz_status variable along with the exit status from
the decompression commands. Later, when this variable is examined
for nonzero status codes, numerals from dates in the ‘diff’ output
make it appear as though decompression failed.
So let the ‘diff’ output leak to standard output with another file
descriptor. (This trick is used in all similar contexts elsewhere
in xzdiff and in the analogous context in gzip’s zdiff script.)
It can be somewhat confusing that
less < some_file.txt
works fine, whereas
xzless < some_file.txt.xz
does not. Since version 429, ‘less’ allows a filter specified in
the LESSOPEN environment variable to preprocess its input even if
it comes from standard input, if $LESSOPEN begins with ‘|-’. So
set $LESSOPEN to take advantage of this feature.
Check less’s version at runtime so xzless can continue to work
with older versions.
lots of comments from Doxygen.
It seems that the Doxygen authors' intent is to not apply
their copyright on generated files, but since it doesn't
matter for XZ Utils at all, better safe than sorry.
Installation and packaging instructions were added.
README and other generic docs were revised.
Some of the documentation files are now installed to $docdir.
