You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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:
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:
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.
The text was updated successfully, but these errors were encountered: