Giter Site home page Giter Site logo

miniz's People

miniz's Issues

Unsigned integer overflow 

Compiling with clang++ and the `-fsanitize=unsigned-integer-overflow` flag 
(http://clang.llvm.org/docs/UsersManual.html) exposes a few unsigned overflow 
issues:

../src/miniz.c:1929:7: runtime error: unsigned integer overflow: 0 - 1 cannot 
be represented in type 'mz_uint' (aka 'unsigned int')
../src/miniz.c:964:35: runtime error: unsigned integer overflow: 0 - 1 cannot 
be represented in type 'size_t' (aka 'unsigned long')


Originally described at https://github.com/developmentseed/node-blend/issues/27

Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 2:04

Compress a folder 

 Hi again.I can't find a way to compress a folder to zip.Is it possible?

Original issue reported on code.google.com by [email protected] on 14 Oct 2014 at 3:36

Can not be used as drop-in replacement for zlib with libpng 

What steps will reproduce the problem?
1. Make libpng use miniz instead of zlib, by compiling miniz as a static 
library, modifying the libpng makefile to use the compiled library instead of 
zlib, and creating a header file out of miniz.c, to impersonate the original 
zlib.h.

What is the expected output? What do you see instead?
libpng can't be compiled - linker complains about missing inflateReset and 
inflateReset2.


What version of the product are you using? On what operating system?
miniz v115_r4 and libpng-1.6.12 cross-compiling for a custom SuperH target with 
gcc 4.8.2. The cross-compiling setup is tested and works fine.


Please provide any additional information below.

Seems to be a problem similar to issue #16, except here it's not a macro that's 
missing, but two zlib functions that have no equivalents on miniz.
This is especially disappointing because the project homepage claims it is 
tested as a drop-in replacement for zlib, and mentions libpng as an example.

Original issue reported on code.google.com by [email protected] on 13 Aug 2014 at 2:27

Inclusion of <time.h> happens before #define block? 

It seems that this code:

#if !defined(MINIZ_NO_TIME) && !defined(MINIZ_NO_ARCHIVE_APIS)
#include <time.h>
#endif

Occurs in "miniz.c" *before* the big block of commented-out #defines, meaning 
that the include happens regardless of how you've chosen to configure miniz for 
your project. This looks like a bug to me. I'm very new as a miniz user though, 
so I could be mistaken.

I noticed this in version v114_r1.7.

Original issue reported on code.google.com by [email protected] on 1 Oct 2012 at 12:59

Memory Leak in PNG write function 

What steps will reproduce the problem?
1. call tdefl_write_image_to_png_file_in_memory_ex() in test code
2. run a memory leak detector

What is the expected output? What do you see instead?

There is a memory leak in tdefl_write_image_to_png_file_in_memory_ex()
out_buf.m_pBuf is not freed on success

What version of the product are you using? On what operating system?

miniz.c v1.15 
Windows 7 Pro x64

Please provide any additional information below.

Add MZ_FREE(out_buf.m_pBuf); before return statement (line 2827)

Original issue reported on code.google.com by [email protected] on 14 Oct 2013 at 11:58

miniz fails to decompress valid ZIP archive 

What steps will reproduce the problem?
1. Complie attached test_crash.c with latest miniz.
2. Run it against attached test.zip.

What is the expected output? What do you see instead?
Expected is MANIFEST.MF contents since test.zip is a valid archive.
However it fails to decompress file contents.

What version of the product are you using? On what operating system?
Miniz 1.11b, Win7 and GNU/Linux (gcc 4.1.2)

Please provide any additional information below.

I've discovered that failure occurs in tinfl_decompress() routine:

...
        TINFL_HUFF_DECODE(26, dist, &r->m_tables[1]);
        num_extra = s_dist_extra[dist]; dist = s_dist_base[dist];
        if (num_extra) { mz_uint extra_bits; TINFL_GET_BITS(27, extra_bits, num_extra); dist += extra_bits; }

        dist_from_out_buf_start = pOut_buf_cur - pOut_buf_start;
        if ((dist > dist_from_out_buf_start) && (decomp_flags & TINFL_FLAG_USING_NON_WRAPPING_OUTPUT_BUF))
        {
          TINFL_CR_RETURN_FOREVER(37, TINFL_STATUS_FAILED);
        }
...


dist occures to be 2049 which is much greater than dist_from_out_buf_start thus 
decompression fails.

Original issue reported on code.google.com by [email protected] on 22 Nov 2011 at 6:59

Attachments:

Remove archived file from central directory 

It would be great if the library supported file removal from the central 
directory and compress of a new file to a specific file index. This would let 
us overwrite a single file content with new data without wasting memory.

Original issue reported on code.google.com by [email protected] on 6 Jun 2014 at 4:35

mingw32 compilation configuration 

What steps will reproduce the problem?
1. Use tdm-mingw32 to compile miniz on win32

What is the expected output? What do you see instead?

Excepting quiet compilation,
got some undefined references instead.

What version of the product are you using? On what operating system?
1.11 / win32

Please provide any additional information below.

My solution:
add 
#define __forceinline inline
#include <time.h> 
at the beginning of the source.

and
mingw32 doesn't have _fseeki64/_ftelli64,
therefore I changed the corresponding macro to ftello64/fseeko64 as 
alternatives. They seems work the same way. I hope :)


      #if defined(__MINGW32__)

         #define MZ_FTELL64 ftello64

         #define MZ_FSEEK64 fseeko64

      #else

         #define MZ_FTELL64 _ftelli64

         #define MZ_FSEEK64 _fseeki64

      #endif

Original issue reported on code.google.com by [email protected] on 30 Oct 2011 at 9:07

the zip file created by example3 that is not decompressed by winzip/winrar/7zip? 

What steps will reproduce the problem?
1.using example3 to compress the *.txt to *.zip
2.and then decompress *.zip by using winzip/winrar/7zip
3.fail

What is the expected output? What do you see instead?

can decompress by other software
What version of the product are you using? On what operating system?
 miniz.c v1.14 , windows xp

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 7 Aug 2013 at 8:39

Package Pre-Built Binaries Separately 

I would like to suggest that the pre-built binaries be packaged separately from 
the source code.  The intent would be to better facilitate Linux distribution 
packaging.  Fedora, for example, does not permit pre-built binaries in its 
packages.

See:
http://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_bin
aries_or_libraries

Thank you for for considering.

Original issue reported on code.google.com by [email protected] on 15 Oct 2014 at 2:54

mz_zip_writer_add_file does not support directory 

What steps will reproduce the problem?
mz_zip_writer_add_file(&zip_archive, "dir/", "dir/", NULL, 0, 0);

What is the expected output? What do you see instead?
Expected to see it read directory modified time and other attribute and add an 
entry to zip_archive.
But the function return false every time.

What version of the product are you using? On what operating system?
v115_r4
win8.1

Please provide any additional information below.
The only way I can find to add directory entry is mz_zip_writer_add_mem, but 
the modified time will be now instead of actual modified time of the directory.

Original issue reported on code.google.com by jayxon on 10 Apr 2014 at 10:42

Multiple linker errors in VisualStudio 

What steps will reproduce the problem?
1.Create new console project in VisualStudio2012
2.Add miniz.c and main.c
3.Addd "#include 'miniz.c' " before "main" function

What is the expected output? What do you see instead?
Expected-compilation success.Instead I am getting:

1>miniz.obj : error LNK2005: _mz_zip_reader_extract_to_mem_no_alloc already 
defined in main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_file_stat already defined in 
main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_get_filename already defined in 
main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_get_num_files already defined in 
main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_init already defined in main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_init_file already defined in 
main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_init_mem already defined in main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_is_file_a_directory already defined 
in main.obj
1>miniz.obj : error LNK2005: _mz_zip_reader_is_file_encrypted already defined 
in main.obj

etc.. 

Also,if I use prebuilt VS project which come with the library,it compiles and 
works fine.The problem only appears in a new project.

What version of the product are you using? On what operating system?

Windows7 64bit  VisualStudio 2012


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 14 Oct 2014 at 1:23

Wrong number of files returned for more that 65535 entries 

What steps will reproduce the problem?
1. Open a zip file with more than 65535 entries
2. Use the mz_zip_reader_get_num_files function to read it and you'll see it 
returns 65535 entries, instead of the correct value.

What version of the product are you using? On what operating system?
trunk

Original issue reported on code.google.com by [email protected] on 5 Jul 2014 at 12:10

[PATCH] supports armcc 

Current miniz doesn't support ARM compiler. When compiling with ARM compiler, 
the following error occurred.

"xxxx/miniz.c", line 2299: Error:  #65: expected a ";"
  static MZ_FORCEINLINE void tdefl_find_match(tdefl_compressor *d, mz_uint lookahead_pos, mz_uint max_dist, mz_uint max_match_len, mz_uint *pMatch_dist, mz_uint *pMatch_len)
                        ^

This patch supports ARM compiler and fixes the error.

Thanks

Original issue reported on code.google.com by [email protected] on 7 Feb 2014 at 10:03

Attachments:

Fixes for you, in a different repo 

Hi,

I've been doing some fixes and pushed them up to this git repository:
https://github.com/paulharris/miniz

I imported the SVN repo, so all the SVN patches are contained within too.

Are you still active in this project?  There are quite a few open bugs that 
seem to be already fixed, or easily fixed elsewhere.

Also note that I'm not the only alternative miniz repo out there,
eg, this one has changes for working on Android:
https://github.com/codefireXperiment/external_libminiz

cheers,
Paul

Original issue reported on code.google.com by [email protected] on 8 Oct 2013 at 3:23

API to delete a file from zip 

I would like miniz to have an API to delete a entry from a exist zip directly. 
At present we need to decompress it and compress again without the file i want 
delete. I would appreciate it if it has an API to do it.

Original issue reported on code.google.com by [email protected] on 22 Oct 2014 at 3:20

Support for reading archive comments 

miniz seems to only support reading file comments from zip files. Unless I'm 
missing something, it seems like the global archive comment (which seems to be 
much more commonly used than per-file comments) cannot be read at the moment. 
It would be nice if this comment text could be extracted from zip files using 
miniz.

Original issue reported on code.google.com by [email protected] on 10 Feb 2014 at 1:00

Need another tinfl_decompress_ function 

Is difficult to understand how I should write a tinfl_decompress_ function that 
would decompress a data stream that is coming from a custom fread() function.

The closest clue seems to be by hacking mz_zip_reader_extract_to_mem_no_alloc().

Original issue reported on code.google.com by [email protected] on 10 Oct 2013 at 7:52

#defines stomp 

You #define crc32 mz_crc32
, which is a function.

The result of this, is that if I do this.

// in another header
class Info
{
   int crc32;
};

// now include miniz, crc32 gets stomped
#include <miniz/miniz.h>

Info info;
info.crc32 = 10; // COMPILE FAIL
because that gets transformed to
info.mz_crc32 = 10;

Instead, perhaps use inline functions, eg

inline etc crc32(buffer, size) { return mz_crc32(buffer,size); }

same performance, less stomping.

Original issue reported on code.google.com by [email protected] on 8 Oct 2013 at 4:19

Decompress consumes an extra byte when extra data are provided 

What steps will reproduce the problem?

1. Provide extra data in the input buffer for tinfl_decompress().
2. An extra byte is consumed beyond the deflated data.
3. The output parameter pIn_buf_size of tinfl_decompress() has an extra byte.

This is a problem for gzip stream data since it has 8 extra bytes after the 
deflated data (4 bytes CRC and 4 bytes original length).  When reading gzip 
stream data, it's often not known when the end of stream is.  One has to read 
as much as data there are and pass them to tinfl_decompress() to let it decode 
the deflated data.  Once tinfl_decompress() stops, the remaining data in the 
buffer are interpreted separately by the caller.

What is the expected output? What do you see instead?

Expect decompress() to consume exactly the number of deflated data, or if an 
extra byte is consumed, let the caller knows so that it can unread the byte in 
the buffer.

What version of the product are you using? On what operating system?
version 1.15.  On Win32.

Please provide any additional information below.

Sample gzip deflated data causing the problem.

[0x73, 0x74, 0x72, 0x76, 0x71, 0x75, 0x73, 0xF7, 0xE0, 0xE5, 0x02, 0x00,
  0x94, 0xA6, 0xD7, 0xD0,  0x0A, 0x00, 0x00, 0x00]

The first 12 bytes are the deflated data.  The next 4 bytes are the CRC.  The 
last 4 bytes are the original length.  tinfl_decompress() should stop after 12 
bytes.

The original data is "ABCDEFGH\r\n"

--------

I found the problem where it's too late to call TINFL_HUFF_BITBUF_FILL().  It 
is only called when only 1 byte are left in the input buffer, which is never 
triggered for the above case where there are 8 extra bytes.

I have changed the number of bytes to check from ((pIn_buf_end - pIn_buf_cur) < 
2) to ((pIn_buf_end - pIn_buf_cur) < 16) and that works.  See attached file for 
the diffs.

It's not an airtight fix since it only helps the cases with input buffer upto 
15 extra bytes.  It makes miniz work on gzip files.

The best fix would be to consume the extra byte as needed but fix up the 
pointer by counting how many bits left in bit_buf.  Since the data are in a 
buffer, it's easy to move the pointer back as needed.

Original issue reported on code.google.com by [email protected] on 18 Oct 2013 at 10:01

Attachments:

mz_crc32 fails on x86_64 

using a 32bit unsigned int instead of a 64bit unsigned long fixes the problem.

-mz_ulong mz_crc32(mz_ulong crc, const unsigned char *ptr, size_t buf_len);
+mz_uint32 mz_crc32(mz_uint32 crc, const unsigned char *ptr, size_t buf_len);

also the typedef for mz_uint32 must be moved to preceed this.

Original issue reported on code.google.com by [email protected] on 24 Feb 2012 at 2:28

clang 3.1 with -std=c11 fails to compile miniz.c with narrowing conversions error 

See 
http://stackoverflow.com/questions/4434140/narrowing-conversions-in-c0x-is-it-ju
st-me-or-does-this-sound-like-a-breakin

It seems to me this might actually be a compiler bug because clang thinks 
"\0\0\04\02\06"[num_chans] isn't a constant expression. However, this fixes the 
problem:

@@ -2765,6 +2765,7 @@ mz_uint tdefl_create_comp_flags_from_zip_params(int 
level, int window_bits, int
 // http://altdevblogaday.org/2011/04/06/a-smaller-jpg-encoder/.
 void *tdefl_write_image_to_png_file_in_memory(const void *pImage, int w, int h, int num_chans, size_t *pLen_out)
 {
+  static const mz_uint8 chans[] = {0x00, 0x00, 0x04, 0x02, 0x06};
   tdefl_compressor *pComp = (tdefl_compressor *)MZ_MALLOC(sizeof(tdefl_compressor)); tdefl_output_buffer out_buf; int i, bpl = w * num_chans, y, z; mz_uint32 c; *pLen_out = 0;
   if (!pComp) return NULL;
   MZ_CLEAR_OBJ(out_buf); out_buf.m_expandable = MZ_TRUE; out_buf.m_capacity = 57+MZ_MAX(64, (1+bpl)*h); if (NULL == (out_buf.m_pBuf = (mz_uint8*)MZ_MALLOC(out_buf.m_capacity))) { MZ_FREE(pComp); return NULL; }
@@ -2778,7 +2779,7 @@ void *tdefl_write_image_to_png_file_in_memory(const void 
*pImage, int w, int h,
   *pLen_out = out_buf.m_size-41;
   {
     mz_uint8 pnghdr[41]={0x89,0x50,0x4e,0x47,0x0d,0x0a,0x1a,0x0a,0x00,0x00,0x00,0x0d,0x49,0x48,0x44,0x52,
-      
0,0,(mz_uint8)(w>>8),(mz_uint8)w,0,0,(mz_uint8)(h>>8),(mz_uint8)h,8,"\0\0\04\02\
06"[num_chans],0,0,0,0,0,0,0,
+      
0,0,(mz_uint8)(w>>8),(mz_uint8)w,0,0,(mz_uint8)(h>>8),(mz_uint8)h,8,chans[num_ch
ans],0,0,0,0,0,0,0,
       (mz_uint8)(*pLen_out>>24),(mz_uint8)(*pLen_out>>16),(mz_uint8)(*pLen_out>>8),(mz_uint8)*pLen_out,0x49,0x44,0x41,0x54};
     c=(mz_uint32)mz_crc32(MZ_CRC32_INIT,pnghdr+12,17); for (i=0; i<4; ++i, c<<=8) ((mz_uint8*)(pnghdr+29))[i]=(mz_uint8)(c>>24);
     memcpy(out_buf.m_pBuf, pnghdr, 41);

Original issue reported on code.google.com by [email protected] on 22 Jul 2012 at 7:31

PATCH: Undefined symbols for 64-bit variants of stdio functions on Mac OS X 

Projects using the latest trunk version of miniz.c on Mac OS X fail to build 
because of undefined symbols for `_fopen64`, `_fseeko64`, `_ftello64`, 
`_freopen64`. 

The attached patch (based on 
http://stackoverflow.com/questions/4003479/how-to-enable-large-file-support-unde
r-darwin) fixes the problem.

Original issue reported on code.google.com by [email protected] on 28 Oct 2013 at 4:46

Attachments:

g++ inlining warnings (with solution) 

Problem:
========
Compilation of miniz.c using 

    g++ -std=c++11 file.cc 

results in errors of the sort:

    miniz.c:3393:27: warning: always_inline function might not be inlinable [-Wattributes]



Solution:
=========

<   #define MZ_FORCEINLINE inline __attribute__((__always_inline__))

---
>   #define MZ_FORCEINLINE __attribute__((__always_inline__))

Original issue reported on code.google.com by [email protected] on 24 May 2013 at 11:32

Has anyone got it working on android devices (arm based platforms) 

Just curious has anyone got miniz working on arm-based Android devices. 

I had a stripped down version of miniz (v115_r4), which contains only 
mz_compress() and mz_uncompress() functions and their dependenices. It is 
working well on a Ubuntu desktop, however, after I ported it to Android, I 
found that if the compress block size is 16K bytes or bigger, the compression 
can easily fail. Most time it failed silently, I only noticed the problem when 
trying to uncompress the compressed the content. 

Confirmed the issue is on the compression side by trying to uncompress the same 
compressed block using miniz on Ubuntu PC, it failed with the same error: 
MZ_DATA_ERROR. Also tried using miniz on Ubuntu PC to compress and uncompress 
the same original data block (16Kbytes), and it works fine.

I will for sure debug further and report back to this thread, just in case 
someone already done the simliar porting work and knows what need to be tweaked 
...

Btw, Rich, very nice tool, thanks a lot for sharing.

Original issue reported on code.google.com by [email protected] on 24 Oct 2014 at 3:36

Finding entries fails for some files if MZ_ZIP_FLAG_DO_NOT_SORT_CENTRAL_DIRECTORY used 

What steps will reproduce the problem?
1. Create a ZIP file with entries in this order: C, B, A.
2. Open the ZIP file with MZ_ZIP_FLAG_DO_NOT_SORT_CENTRAL_DIRECTORY.
3. Attempt to locate entry C (no flags).

What is the expected output? What do you see instead?
I expect to find entry C at index 0. Instead, it is not found.

What version of the product are you using? On what operating system?
miniz 1.14 on Windows 7 (x64).

Please provide any additional information below.
The mz_zip_reader_locate_file() function does not seem to detect that 
MZ_ZIP_FLAG_DO_NOT_SORT_CENTRAL_DIRECTORY was used, and assumes the central 
directory is sorted. This causes the subsequent binary search for C to fail.

There seems to be a check for whether m_sorted_central_dir_offsets.m_p, but 
m_sorted_central_dir_offsets is apparently always initialized, regardless of 
whether or not the central directory was actually sorted.

Original issue reported on code.google.com by [email protected] on 8 Feb 2013 at 1:56

Windows "Extract All..." functionality doesn't like tiny files in zip files created by miniz 

What steps will reproduce the problem?
1. Create a small file.  Files as large as 68 bytes failed for me.
2. Zip with example3 "example3 c test.txt test.zip"
3. Right click on file (in Windows) and click "Extract All..." 

What is the expected output? What do you see instead?
EXPECTED: File is extracted correctly
ACTUAL: Windows complains zipped folder is empty

What version of the product are you using? On what operating system?
Windows 7 SP1, miniz 1.1544 example3

Please provide any additional information below.
The file is extracted with 7zip just fine.  I know this is not "your" bug, so I 
don't expect anything to happen with it, but I thought I would let you know.  
7zip DOES generate a zip file that Windows likes, FWIW.  I am attaching the zip 
file that windows doesn't like.  If there are large enough files in the zip 
file so windows doesn't think it is empty, it extracts those, and gives a 
0x80004005 error when it finds the files that are too small.

Original issue reported on code.google.com by [email protected] on 8 Jan 2014 at 5:07

Attachments:

mz_reader_extract_to_mem_noalloc() fails with non-NULL user buffer 

What steps will reproduce the problem?
1. Create a ZIP with an entry with a larger compressed size than uncompressed 
size. (Not sure if this is a necessary condition.)
2. Call mz_reader_extract_to_mem_noalloc with a non-NULL user buffer.

What is the expected output? What do you see instead?
I expect the extracted output, but the procedure fails instead.

What version of the product are you using? On what operating system?
1.14 on Visual Studio 2010 (32-bit). Also replicated with GCC on Cygwin.

Please provide any additional information below.

The problem seems to be on line 3539:

  else if (pUser_read_buf)
  {
    // Use a user provided read buffer.
    if (!user_read_buf_size)
      return MZ_FALSE;
    pRead_buf = (mz_uint8 *)pUser_read_buf;
    read_buf_size = user_read_buf_size;
    read_buf_avail = 0;
    comp_remaining = file_stat.m_uncomp_size;
  }

Judging from the surrounding code, comp_remaining = file_stat.m_comp_size, not 
m_uncomp_size. This would explain why cases with a NULL pUser_read_buf works 
fine.

Original issue reported on code.google.com by [email protected] on 23 Aug 2012 at 7:25

Suggestion: Filter parameter for tdefl_write_image_to_png_file_in_memory() 

The simple PNG writer sets all of the rows to unfiltered '0' 
I've made a low-profile change to the method in miniz.c in my own code to 
accept a pre-filtered input image. It simply passes an array of filter types to 
the function, and places them in the image data to be compressed.

tdefl_write_image_to_png_file_in_memory_ex()
line 2802 : Add parameter "mz_uint8* filters"
line 2813 : Replace second parameter of the first call to 
tdefl_compress_buffer() [&z] 
            with (filters == NULL ? &t : filters+(flip ? (h - 1 - y) : y))

tdefl_write_image_to_png_file_in_memory()
line 2831 : Add parameter "mz_uint8* filters"
line 2834 : Pass filters to tdefl_write_image_to_png_file_in_memory_ex()

Alternatively, set the parameter to NULL on line 2834 to reduce the impact on 
the API 

I'm using t (mz_uint8) instead of z (int), because the function is passing a 
byte of data. In face, z should probably also be mz_uint8 for its use in 
writing the header.

Original issue reported on code.google.com by [email protected] on 25 Jan 2014 at 6:35

Compiler warnings on strict aliasing 

What steps will reproduce the problem?
1. gcc -Wall -Werror -O2 miniz.c
2.
3.

What is the expected output? What do you see instead?
Expected output: Compiler errors due to no main().
Actual output:
Compiler errors due to type punning.
miniz.c: In function ‘tdefl_find_match’:
miniz.c:2270:3: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
miniz.c:2282:7: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
miniz.c:2282:7: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
miniz.c:2282:7: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
miniz.c:2294:7: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
miniz.c: In function ‘tdefl_compress_fast’:
miniz.c:2367:7: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]

What version of the product are you using? On what operating system?
9.1.15, all MINIZ_NO_* enabled. Linux Mint 15, AMD64, GCC 4.7.3-1ubuntu1.

Please provide any additional information below.
Disabling warnings, optimization, or both, makes this go away.

Original issue reported on code.google.com by [email protected] on 24 Nov 2013 at 5:02

1 byte input & output buffer not working 

What steps will reproduce the problem?
1. port the example buftest.c and xzminidec.c from the xz-embedded library to 
miniz with a 1 byte input and output buffer

What is the expected output? What do you see instead?
I see duplicated bytes in the output

What version of the product are you using? On what operating system?
v111b

Please provide any additional information below.
I think porting the test/examples/demos from the xz-embedded or the xz library 
proper and/or other decompression libraries and including them into miniz would 
be a good idea.

Original issue reported on code.google.com by [email protected] on 20 Jul 2011 at 6:21

Miniz fails to locate file in ZIP archive 

Summary: The function mz_zip_extract_archive_file_to_heap() can fail to locate 
an archive member, because it uses binary search in the central directory, even 
if that central directory was never sorted because the   
MZ_ZIP_FLAG_DO_NOT_SORT_CENTRAL_DIRECTORY flag was specified when initializing 
the archive reader.

The problem is caused by the following two lines in mz_zip_reader_locate_file():

 if (((flags & (MZ_ZIP_FLAG_IGNORE_PATH | MZ_ZIP_FLAG_CASE_SENSITIVE) == 0) && (!pComment) && (pZip->m_pState->m_sorted_central_dir_offsets.m_p))
    return mz_zip_reader_locate_file_binary_search(pZip, pName);

The check whether pZip->m_pState->m_sorted_central_dir_offsets.m_p is 
initialized is probably meant to determine whether the central directory was 
sorted.  However, the pZip->m_pState->m_sorted_central_dir_offsets array is 
*always* initialized, irrespective of whether the central directory was sorted 
or not (see the definition of  mz_zip_reader_read_central_dir()).

Hence, a different way of checking whether the central directory has been 
sorted should be implemented.

Original issue reported on code.google.com by [email protected] on 9 Sep 2013 at 1:45

Extract all files from zip without knowing their names. 

 Hi.I wonder if it is possible to extract everything from the .zip without knowing compressed files names.
I mean,this method:

    mz_zip_reader_extract_file_to_file

asks for file names to extract.But if the .zip was created somewhere else I 
have no idea of those names.

Thanks.

Original issue reported on code.google.com by [email protected] on 14 Oct 2014 at 3:02

Using miniz.c in multiple projects can cause symbol clashes 

miniz is designed as a single file to be included by another source file via 
#include "miniz.c" as stated in the example applications. This works fine when 
miniz is used within one project. When two projects using miniz unexpected 
results arise.

Situation:

Shared library A includes miniz.c. Application B also includes miniz.c. 
Application A will load B.


Problem:

When B loads library A there are two copies of the symbols related to miniz. 
Depending on the OS, B might fail to load A. Also, depending on the OS the 
miniz that is part of A might be used by B or vice versa. This can be a major 
issue if A and B have different versions (especially if they are not ABI or API 
compatible) of miniz included.


Solutions:

1) Make all parts within miniz.c static. This will make everything in miniz.c 
only visible to what is including it. This will prevent the miniz symbols from 
being exposed publicly.

This could be facilitated by setting a define similar to MINIZ_NO_ARCHIVE_APIS. 
Something like:

#ifdef MINIZ_STATIC
# define MINIZ_STATIC static
#else
# define MINIZ_STATIC
#endif

Then any any function that would be considered public would be prefixed by 
MINIZ_STATIC:

MINIZ_STATIC int mz_uncompress(...

2) Break miniz.c appart into miniz.h and miniz.c to facilitate building and 
installing miniz as a shared library.

Original issue reported on code.google.com by [email protected] on 8 Aug 2012 at 3:14

MINIZ_NO_STDIO option fails to compile 

What steps will reproduce the problem?
1. #define MINIZ_NO_STDIO

What is the expected output? What do you see instead?
'mz_zip_reader_extract_to_file': identifier not found

Please provide any additional information below.
Problem appears to be that mz_zip_reader_extract_file_to_file should not be 
defined in MINIZ_NO_STDIO builds

Solution appears to be to wrap mz_zip_reader_extract_file_to_file in #ifndef 
MINIZ_NO_STDIO
#endif

Original issue reported on code.google.com by [email protected] on 18 May 2012 at 1:10

enumeral and non-enumeral type in conditional expression 

What steps will reproduce the problem?
1. compile with -Wall
2. calls from MZ_MIN and MZ_MAX with different var types like in dict_size = 
MZ_MIN(dict_size + cur_match_len, TDEFL_LZ_DICT_SIZE);

What is the expected output? What do you see instead?
expected are no warning, but i got the warning "enumeral and non-enumeral type 
in conditional expression [enabled by default]"

What version of the product are you using? On what operating system?
1.15r4 with qt 5.0.2 on win7 64bit

Please provide any additional information below.
solved issue with explcit cast. i.e. dict_size = MZ_MIN(dict_size + 
cur_match_len, (mz_uint)TDEFL_LZ_DICT_SIZE);

Original issue reported on code.google.com by [email protected] on 10 Dec 2013 at 5:00

Can not use in libtiff 

What steps will reproduce the problem?
1. replace "zlib.h" with "miniz.c" in tif_zip.c
2. compile and it will report "Z_BINARY is not defined"
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
1.14 on mac

Please provide any additional information below.
Some zlib macros are not defined in miniz.c

Thanks

Original issue reported on code.google.com by [email protected] on 13 Sep 2013 at 12:58

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.