There are type mismatches relative to the zlib definitions.
I'll list the ones I saw below.
One possible issue with this is what happens when a binary compiled using runs with libnxz with the zlib interfaces.
lib/nx_adler32.c
Functions adler32 and adler32_z use const char for the "buf" argument, but the zlib declaration uses Bytef, which I believe resolves to unsigned char .
Our implementation nx_adler32_z also takes a const char *. I'm also worried that this could cause some error in the code for nx_adler32_z, since it does arithmetic manipulation of the values in the buffer, and it is derived from the zlib adler32 function, which expects an unsigned char array.
Function crc32 (lib/nx_crc.c)
This one uses uint64_t instead of uInt for the len parameter. The function that it calls is crc32_ppc, which takes an int.
What happens here? Does the unsinged int from the caller that used get zero-extended to a uint64_t?
Also, our nx_crc32 takes a uin64_t, and calls nx_crc32_z, which iself takes a z_size_t. Note that our crc32 doesn't call nx_crc32, it calls crc32_ppc.
Function crc32_combine and crc32_combine64 both use uint64_t instead of z_off_t and z_off64_t, respectively, in the zlib definition. The type that z_off64_t represents varies according to some preprocessor definitions in zlib.h. I'm not sure what it resolves to in a regular zlib build for ppc64.
Declaration qualifiers
Our declarations don't have the same qualifiers as the ones in zlib.h, e.g. ZEXTERN, ZEXPORT, OF, etc. I'm not sure if these actually resolve to something when you build zlib for ppc64.
mscastanho
commented
2 years ago
There are type mismatches relative to the zlib definitions.
I'll list the ones I saw below.
One possible issue with this is what happens when a binary compiled using runs with libnxz with the zlib interfaces.
Functions adler32 and adler32_z use const char for the "buf" argument, but the zlib declaration uses Bytef, which I believe resolves to unsigned char .
Our implementation nx_adler32_z also takes a const char *. I'm also worried that this could cause some error in the code for nx_adler32_z, since it does arithmetic manipulation of the values in the buffer, and it is derived from the zlib adler32 function, which expects an unsigned char array.
This one uses uint64_t instead of uInt for the len parameter. The function that it calls is crc32_ppc, which takes an int.
What happens here? Does the unsinged int from the caller that used get zero-extended to a uint64_t?
Also, our nx_crc32 takes a uin64_t, and calls nx_crc32_z, which iself takes a z_size_t. Note that our crc32 doesn't call nx_crc32, it calls crc32_ppc.
Function crc32_combine and crc32_combine64 both use uint64_t instead of z_off_t and z_off64_t, respectively, in the zlib definition. The type that z_off64_t represents varies according to some preprocessor definitions in zlib.h. I'm not sure what it resolves to in a regular zlib build for ppc64.
Our declarations don't have the same qualifiers as the ones in zlib.h, e.g. ZEXTERN, ZEXPORT, OF, etc. I'm not sure if these actually resolve to something when you build zlib for ppc64.