Minor issues compiling and running on a retro computer

[marciot]

I am trying to compile "miniz" for a 1992 Macintosh LC II using a compiler native to that time (Metrowerks CodeWarrior 1.4) and I have encountered some very minor issues (frankly, this shocked me, as I had expected major issues, so thank you for the fantastic library that runs great on a 32 year old platform).

The issues:

Compilation error due to s_tdefl_num_probes redefined

s_tdefl_num_probes is defined twice in miniz.c. This error happens on modern Linux compilers too:

miniz.c:1254:22: error: uninitialized const ‘s_tdefl_num_probes’ [-fpermissive]
 1254 | static const mz_uint s_tdefl_num_probes[11];
      |                      ^~~~~~~~~~~~~~~~~~
miniz.c:2113:22: error: redefinition of ‘const mz_uint s_tdefl_num_probes [11]’
 2113 | static const mz_uint s_tdefl_num_probes[11] = { 0, 1, 6, 32, 16, 32, 128, 256, 512, 768, 1500 };
      |                      ^~~~~~~~~~~~~~~~~~
miniz.c:1254:22: note: ‘const mz_uint s_tdefl_num_probes [11]’ previously declared here
 1254 | static const mz_uint s_tdefl_num_probes[11];

I simply moved the second definition, with the initializers, to the location of the first definition. Easy fix.

Decompression fails when sizeof(mz_uint) == 2

Example1.c fails on decompression when "sizeof(mz_uint) == 2", as it is on my retro machine. The compressed byte codes match a modern Linux machine, so the issue is only in the decompression.

On my platform, an "unsigned int" is 16 bits, while an "unsigned long" is 32 bits. Knowing this, I adjusted "mz_int16" and "mz_uint32" to "unsigned short" and "unsigned long" respectively, but I had left "mz_uint" as the default of "unsigned int".

It turned out this needed to be changed to "unsigned long" for decompression to work. You can reproduce the problem on a modern machine by making the following change:

/* ------------------- Types and macros */
typedef unsigned char mz_uint8;
typedef signed short mz_int16;
typedef unsigned short mz_uint16;
typedef unsigned int mz_uint32;
typedef unsigned short mz_uint;  // <<< change this to cause decompression to fail
typedef int64_t mz_int64;
typedef uint64_t mz_uint64;
typedef int mz_bool;

I would expect the proper fix would be to either change the decompression code to use "mz_uint32" instead of "mz_uint" where needed, or to add a check to make sure "mz_uint" is at least 32 bits, something along the lines of:

typedef unsigned char mz_validate_uint[sizeof(mz_uint) >= 4 ? 1 : -1];

Compilation fails when the compiler does not know about "uint64_t" or "int64_t"

Thirty two years ago, 64-bit types were not implemented by compilers. Miniz seems to use these primarily for archiving and they are not used for the core routines. I simply enabled MINIZ_NO_ARCHIVE_APIS to get around the majority of the problem and commented out the few remaining places where "mz_uint64" and "mz_int64" were used.

I also had to remove the "#include <stdint.h>" header, since that is not present on older compilers and seems to be present only for the 64-bit types.

It might be nice to add a compilation flag "MINIZ_USE_64BIT_INTS" that can be disabled to remove that header and any references to "mz_uint64" and "mz_int64", as this would make it easier to compile "miniz" on ancient hardware.

Compilation fails due to TDEFL_OUT_BUF_SIZE being non-integer

Several arrays are initialized with TDEFL_OUT_BUF_SIZE, however, the definition of this constant evaluates to a non-integer. I found out that coercing it to an int solved the problem:

    TDEFL_LZ_CODE_BUF_SIZE = 24 * 1024,
    TDEFL_OUT_BUF_SIZE = (unsigned int)(TDEFL_LZ_CODE_BUF_SIZE * 13) / 10,

Compilation fails due to TDEFL_LZ_CODE_BUF_SIZE being too large

My compiler limits arrays to 65,536, so I simply had enable TDEFL_LESS_MEMORY so TDEFL_LZ_CODE_BUF_SIZE was within bounds. I don't think anything needs to be changed in the library, but I thought I would mention it for completeness.

[ppinter1]

Just a short note to thank you for solving the first "Compilation error due to s_tdefl_num_probes redefined" issue.

I'm a little surprised this bug survives to a 'modern Linux compiler' era; all the more reason I'm grateful for your fix.