0cch / miniz Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/miniz
Automatically exported from code.google.com/p/miniz
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
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
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
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
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
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
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
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
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
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
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
Defining MINIZ_NO_TIME generates a compiler error (unknown type) because
mz_zip_set_file_times uses the type time_t without time.h being included.
Original issue reported on code.google.com by [email protected]
on 13 Mar 2013 at 8:21
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
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:
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:
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:
Need to open encrypted zip. Is it possible?
Original issue reported on code.google.com by [email protected]
on 18 Oct 2013 at 11:33
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
For libraries that want to use miniz internally without exporting its symbols.
Fixes #7.
Original issue reported on code.google.com by [email protected]
on 29 Sep 2013 at 12:37
Attachments:
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
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
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
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
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
This patch adds a function to read zip files from an already-open FILE*.
We do some silly things with FILE* to work with zip files in our virtual
filesystem, which might not be backed by an actual on-disk file. This lets us
do that.
Original issue reported on code.google.com by [email protected]
on 28 Sep 2013 at 11:24
Attachments:
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
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
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
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
Allocate the tdefl_compressor and tinfl_decompressor structures in C so that
non-C language bindings to tdefL_ and tinfl_ API don't need to worry about
structure size and allocation mechanism.
The patch is based on version 1.16 alpha.
Original issue reported on code.google.com by [email protected]
on 19 Oct 2013 at 10:28
Attachments:
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
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
All examples compile except example 6.
It seems you never tested it.
1.)
For example 6 is missing the VCPROJ file.
2.)
In VS2010 it throws a lot of errors.
1>e:\workspace\miniz\example6.c(36): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(39): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(40): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(41): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(45): error C2065: 'h' : undeclared identifier
1>e:\workspace\miniz\example6.c(46): error C2065: 'c' : undeclared identifier
1>e:\workspace\miniz\example6.c(46): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(46): error C2065: 'X' : undeclared identifier
1>e:\workspace\miniz\example6.c(46): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(47): error C2065: 'X' : undeclared identifier
1>e:\workspace\miniz\example6.c(47): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(47): error C2065: 'c' : undeclared identifier
1>e:\workspace\miniz\example6.c(47): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(48): error C2065: 'c' : undeclared identifier
1>e:\workspace\miniz\example6.c(48): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(48): error C2065: 'X' : undeclared identifier
1>e:\workspace\miniz\example6.c(48): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(49): error C2065: 'X' : undeclared identifier
1>e:\workspace\miniz\example6.c(49): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(49): error C2065: 'c' : undeclared identifier
1>e:\workspace\miniz\example6.c(49): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(50): error C2065: 'X' : undeclared identifier
1>e:\workspace\miniz\example6.c(50): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(50): error C2065: 'c' : undeclared identifier
1>e:\workspace\miniz\example6.c(50): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(51): error C2065: 'c' : undeclared identifier
1>e:\workspace\miniz\example6.c(51): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(51): error C2065: 'X' : undeclared identifier
1>e:\workspace\miniz\example6.c(51): warning C4244: '=' : conversion from 'int'
to 'uint8', possible loss of data
1>e:\workspace\miniz\example6.c(60): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(61): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(64): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(66): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(67): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(68): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(69): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(70): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(72): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(73): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(76): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(77): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(79): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(80): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(83): error C2143: syntax error : missing ';'
before 'const'
1>e:\workspace\miniz\example6.c(84): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(86): error C2275: 'uint8' : illegal use of this
type as an expression
1>e:\workspace\miniz\example6.c(86): error C2065: 'pImage' : undeclared
identifier
1>e:\workspace\miniz\example6.c(86): error C2065: 'iXmax' : undeclared
identifier
1>e:\workspace\miniz\example6.c(86): error C2065: 'iYmax' : undeclared
identifier
1>e:\workspace\miniz\example6.c(89): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(91): error C2143: syntax error : missing ';'
before 'type'
1>e:\workspace\miniz\example6.c(93): error C2065: 'iY' : undeclared identifier
1>e:\workspace\miniz\example6.c(93): error C2065: 'iY' : undeclared identifier
1>e:\workspace\miniz\example6.c(93): error C2065: 'iYmax' : undeclared
identifier
1>e:\workspace\miniz\example6.c(93): error C2065: 'iY' : undeclared identifier
1>e:\workspace\miniz\example6.c(95): error C2065: 'Cy' : undeclared identifier
1>e:\workspace\miniz\example6.c(95): error C2065: 'CyMin' : undeclared
identifier
1>e:\workspace\miniz\example6.c(95): error C2065: 'iY' : undeclared identifier
1>e:\workspace\miniz\example6.c(95): error C2065: 'PixelHeight' : undeclared
identifier
1>e:\workspace\miniz\example6.c(96): error C2065: 'Cy' : undeclared identifier
1>e:\workspace\miniz\example6.c(96): error C2065: 'PixelHeight' : undeclared
identifier
1>e:\workspace\miniz\example6.c(97): error C2065: 'Cy' : undeclared identifier
1>e:\workspace\miniz\example6.c(97): warning C4244: '=' : conversion from
'double' to 'int', possible loss of data
1>e:\workspace\miniz\example6.c(99): error C2065: 'iX' : undeclared identifier
1>e:\workspace\miniz\example6.c(99): error C2065: 'iX' : undeclared identifier
1>e:\workspace\miniz\example6.c(99): error C2065: 'iXmax' : undeclared
identifier
1>e:\workspace\miniz\example6.c(99): error C2065: 'iX' : undeclared identifier
1>e:\workspace\miniz\example6.c(101): error C2065: 'pImage' : undeclared
identifier
1>e:\workspace\miniz\example6.c(101): error C2065: 'iX' : undeclared identifier
1>e:\workspace\miniz\example6.c(101): error C2065: 'iY' : undeclared identifier
1>e:\workspace\miniz\example6.c(101): error C2065: 'iXmax' : undeclared
identifier
1>e:\workspace\miniz\example6.c(101): warning C4047: 'initializing' : 'uint8 *'
differs in levels of indirection from 'int'
1>e:\workspace\miniz\example6.c(103): error C2065: 'Cx' : undeclared identifier
1>e:\workspace\miniz\example6.c(103): error C2065: 'CxMin' : undeclared
identifier
1>e:\workspace\miniz\example6.c(103): error C2065: 'iX' : undeclared identifier
1>e:\workspace\miniz\example6.c(103): error C2065: 'PixelWidth' : undeclared
identifier
1>e:\workspace\miniz\example6.c(106): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(106): warning C4244: '=' : conversion from
'double' to 'int', possible loss of data
1>e:\workspace\miniz\example6.c(107): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(107): warning C4244: '=' : conversion from
'double' to 'int', possible loss of data
1>e:\workspace\miniz\example6.c(108): error C2065: 'Zx2' : undeclared identifier
1>e:\workspace\miniz\example6.c(108): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(108): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(109): error C2065: 'Zy2' : undeclared identifier
1>e:\workspace\miniz\example6.c(109): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(109): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'IterationMax' : undeclared
identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'Zx2' : undeclared identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'Zy2' : undeclared identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'ER2' : undeclared identifier
1>e:\workspace\miniz\example6.c(111): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(113): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(113): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(113): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(113): error C2065: 'Cy' : undeclared identifier
1>e:\workspace\miniz\example6.c(114): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(114): error C2065: 'Zx2' : undeclared identifier
1>e:\workspace\miniz\example6.c(114): error C2065: 'Zy2' : undeclared identifier
1>e:\workspace\miniz\example6.c(114): error C2065: 'Cx' : undeclared identifier
1>e:\workspace\miniz\example6.c(115): error C2065: 'Zx2' : undeclared identifier
1>e:\workspace\miniz\example6.c(115): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(115): error C2065: 'Zx' : undeclared identifier
1>e:\workspace\miniz\example6.c(116): error C2065: 'Zy2' : undeclared identifier
1>e:\workspace\miniz\example6.c(116): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(116): error C2065: 'Zy' : undeclared identifier
1>e:\workspace\miniz\example6.c(119): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(120): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(120): warning C4333: '>>' : right shift by too
large amount, data loss
1>e:\workspace\miniz\example6.c(123): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(123): error C2065: 'MinIter' : undeclared
identifier
1>e:\workspace\miniz\example6.c(124): error C2065: 'MinIter' : undeclared
identifier
1>e:\workspace\miniz\example6.c(124): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(125): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(125): error C2065: 'MaxIter' : undeclared
identifier
1>e:\workspace\miniz\example6.c(126): error C2065: 'MaxIter' : undeclared
identifier
1>e:\workspace\miniz\example6.c(126): error C2065: 'Iteration' : undeclared
identifier
1>e:\workspace\miniz\example6.c(130): error C2065: 'iY' : undeclared identifier
1>e:\workspace\miniz\example6.c(130): fatal error C1003: error count exceeds
100; stopping compilation
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Original issue reported on code.google.com by [email protected]
on 18 Apr 2015 at 3:46
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:
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
What steps will reproduce the problem?
1. Create zip file
2. Append zip file to arbitrary data (with zip at end)
3. Try to read zip using miniz
What is the expected output? What do you see instead?
I expect this to work since the zip format can be appended to anything that
still work (IE: self extracting zips are simply zips appended to binaries)
Please provide any additional information below.
If I change the line at about 3041 where you read the `cdir_ofs` to instead
calculate it based on previous knowledge, it works. You can even calculate the
difference between the actual offset with the declared offset to detect how
many bytes were inserted before the zip.
// This is the old line that reads the offset form the file
cdir_ofs = MZ_READ_LE32(pBuf + MZ_ZIP_ECDH_CDIR_OFS_OFS);
// If you replace it with this code, it will work for embedded zips.
cdir_ofs = cur_file_ofs - cdir_size;
Original issue reported on code.google.com by [email protected]
on 17 Nov 2014 at 6:32
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
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
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
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
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:
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.