* default setting is to use one thead
* multiple threads can be set using the lzma options
* old behavior can be forced by defining BOOST_IOSTREAMS_LZMA_NO_MULTITHREADED
- travis with valgrind, cppcheck, ubsan, codecov, covscan (future)
- appveyor with MSVC 2010 through 2017, cygwin 32/64, mingw 32/64
- README, LICENSE, etc.
Additional fixes for cygwin builds to work
Non-blocking adapter read() wasn't tracking amount read properly which
could cause an infinite loop when underlying (infinite) source returns amounts
smaller than requested. Also amounts read previously were
overwritten by subsequent calls.
Needs lzma.jam file in tools/build module.
See also trac ticket 7534.
The code has been around in random places since some time,
I only added tests and build system updates and
minor fixes for issues those tests discovered.
This fixes a problem where the gzip_decompressor would fail the CRC
check when reading a multipart gzip file that had been written using
Z_FULL_FLUSH, and contains an empty part (with a 0 CRC).
Including a unit test that exposes the bug.
Was getting this error:
{{{
gzip_test.cpp: In function 'void header_test()':
gzip_test.cpp:134: error: narrowing conversion of '139' from 'const int' to 'const char' inside { }
gzip_test.cpp:134: error: narrowing conversion of '156' from 'int' to 'const char' inside { }
gzip_test.cpp:134: error: narrowing conversion of '243' from 'int' to 'const char' inside { }
}}}
Although it's only a warning in later versions of gcc.
[SVN r78385]
Based on Zhuo Qiang's patch with added tests and support
for `operator=`.
I also used `codecvt_type` to detect `filesystem3::path`
instead of `string_type`. Using `string_type` made
`filesystem2::path` ambiguous because it has both
`string_type` and `external_string_type` members.
The member types are a bit arbitrary, but a more precise
distinction would probably also be more expensive.
[SVN r72382]
* Deprecate the old 'close_on_exit' constructors.
* Introduce new constructors from file handle, taking either
`never_close_handle` or `close_handle`.
* Close current file handle when opening a new file handle,
if it would have been closed in the destructor.
[SVN r63430]
