On 2015-05-28 Gabi Davar wrote:
> Please note that it is a very bad idea to mix runtimes on Windows

I had thought it's not a problem (excluding debugging) with liblzma
because I had remembered that liblzma doesn't expose any libc/runtime-
specific things (like file descriptors) via its API. Now that I checked
the API functions, I see I was wrong and there are a few functions that
allocate memory and expect the application to free it instead of calling
some other liblzma function to free it. This is obviously won't work if
the runtimes differ.

List of the functions:

    lzma_block_header_decode
    lzma_filters_copy
    lzma_properties_decode
    lzma_filter_flags_decode

The good news is that most applications have no need to use those
functions since they aren't needed for the most common tasks. xz uses
some of those though, so using e.g. MinGW-w64-built xz.exe with
MSVC-built liblzma.dll cannot work to decompress .lzma files or to view
information about .xz files with "xz -lvv" (only the max verbosity
level should be affected). I haven't actually tried mixing MinGW-w64 and
MSVC code this way yet, but I will try some day for fun.

Those functions and many other liblzma functions take a pointer to
lzma_allocator structure which can be used to specify different memory
allocation functions than malloc() and free(). This way the problem can
be worked around in theory, but I guess few would figure it out in
case they needed those few functions.

So yeah, mixing runtimes on Windows is bad. It's hard to do it correctly
for every detail.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Reply via email to