aboutsummaryrefslogtreecommitdiff
path: root/src/xz/util.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-03-11xz: Never use thousand separators in DJGPP builds.Lasse Collin1-2/+12
DJGPP 2.05 added support for thousands separators but it's broken at least under WinXP with Finnish locale that uses a non-breaking space as the thousands separator. Workaround by disabling thousands separators for DJGPP builds.
2019-06-23xz: Fix some of the warnings from -Wsign-conversion.Lasse Collin1-2/+2
2012-09-28xz: Improve handling of failed realloc in xrealloc.Lasse Collin1-2/+12
Thanks to Jim Meyering.
2010-09-10xz: Multiple fixes.Lasse Collin1-89/+47
The code assumed that printing numbers with thousand separators and decimal points would always produce only US-ASCII characters. This was used for buffer sizes (with snprintf(), no overflows) and aligning columns of the progress indicator and --list. That assumption was wrong (e.g. LC_ALL=fi_FI.UTF-8 with glibc), so multibyte character support was added in this commit. The old way is used if the operating system doesn't have enough multibyte support (e.g. lacks wcwidth()). The sizes of buffers were increased to accomodate multibyte characters. I don't know how big they should be exactly, but they aren't used for anything critical, so it's not too bad. If they still aren't big enough, I hopefully get a bug report. snprintf() takes care of avoiding buffer overflows. Some static buffers were replaced with buffers allocated on stack. double_to_str() was removed. uint64_to_str() and uint64_to_nicestr() now share the static buffer and test for thousand separator support. Integrity check names "None" and "Unknown-N" (2 <= N <= 15) were marked to be translated. I had forgot these, plus they wouldn't have worked correctly anyway before this commit, because printing tables with multibyte strings didn't work. Thanks to Marek Černocký for reporting the bug about misaligned table columns in --list output.
2010-06-11Fix string to uint64_t conversion.Lasse Collin1-2/+8
Thanks to Denis Excoffier for the bug report.
2010-03-07Treat all integer multiplier suffixes as base-2.Lasse Collin1-30/+23
Originally both base-2 and base-10 were supported, but since there seems to be little need for base-10 in XZ Utils, treat everything as base-2 and also be more relaxed about the case of the first letter of the suffix. Now xz will accept e.g. KiB, Ki, k, K, kB, and KB, and interpret them all as 1024. The recommended spelling of the suffixes are still KiB, MiB, and GiB.
2010-01-31Improve displaying of the memory usage limit.Lasse Collin1-0/+7
2010-01-26Fix too small static buffer in util.c.Lasse Collin1-5/+4
This was introduced in 0dd6d007669b946543ca939a44243833c79e08f4 two days ago.
2010-01-24Some improvements to printing sizes in xz.Lasse Collin1-0/+72
2010-01-13Don't read compressed data from a terminal or write itLasse Collin1-4/+4
to a terminal even if --force is specified. It just seems more reasonable this way. The new behavior matches bzip2. The old one matched gzip.
2009-08-29Use even more hackish way to support thousand separators.Lasse Collin1-11/+25
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.
2009-06-26Ugly hack to make it possible to use the thousand separatorLasse Collin1-0/+34
format character with snprintf() on POSIX systems but not on non-POSIX systems and still keep xgettext working.
2009-05-21Support special value "max" where xz and xzdec accept an integer.Lasse Collin1-0/+4
Don't round the memory usage limit in xzdec --help to avoid an integer overflow and to not give wrong impression that the limit is high enough when it may not actually be.
2009-04-13Put the interesting parts of XZ Utils into the public domain.Lasse Collin1-10/+3
Some minor documentation cleanups were made at the same time.
2009-02-05Various code cleanups the the xz command line tool.Lasse Collin1-3/+2
It now builds with MinGW.
2008-11-19Renamed lzma to xz and lzmadec to xzdec. We create symlinksLasse Collin1-0/+199
lzma, unlzma, and lzcat in "make install" for backwards compatibility with LZMA Utils 4.32.x; I'm not sure if this should be the default though.