Conversation
The change to double-width variables led to build Qt failures and possibly out-of-bound writes with dependent software that passes pointers to the traditional 16 or 32 bit variables.
|
Hi, can you try https://github.com/cloudflare/zlib/tree/vlad/aarch64 ? |
|
Hi, can you try https://github.com/cloudflare/zlib/tree/vlad/aarch64 ?
It seems to build not anymore in 32bit mode which makes "universal builds" (multiple architectures in a single binary) very tricky.
|
|
It would be great to provide Mac compatibility. However, I think this patch assumes |
|
I don't see why this patch changes The ASM fix is needed. |
|
Precisely, if you look at the Files Changed you can see that deflate.c, zconf.h, zconf.h.cmakein, zconf.h.in modify the uint64_t, uint32_t, uint8_t references rather than simply including <stdint.h>. But with these modifications, it would be great to see this patch applied to provide MacOS users to have this accelerated library - the speedup is really impressive. |
|
I'll need to find some time to get back to this, but don't hesitate to do a PR of your own. The speed-up is impressive indeed, but you can get an almost identical speed-up from zlib-ng which is based on "zlib current", not on an older version...
Last time I looked at sizeof(unsigned int) I concluded that it should be 32bit on all 32bit and wider architectures (in standard C at least). I admit I didn't consider 16bit architectures, but are those still relevant for this project?
#ifndef uint32_t
That's almost guaranteed not to work universally (= on systems that typedef uint32_t instead of #defining it).
|
|
@RJVB - seems like a good point, this seems like a solution #ifndef UINT32_MAX Thanks for pointing out zlib-ng. Is that completely stable? I note a few outstanding issues and no stable release. |
|
Thanks for pointing out zlib-ng. Is that completely stable? I note a few outstanding issues and no stable release.
AFAIK they have been getting close to a release version, but I haven't looked at it closely for several months. Most development seems to be targetting platforms I have little to no interest in. At least there *is* active development going on.
I'm tempted to say it's mostly stable, and that the devs will probably be interested in anything you do run into.
It's a less obvious choice if you're looking for a drop-in, ABI-compatible replacement, I recall proposing a change to their compatibility mode a while back aimed at making it possible to replace an existing shared libz with NG libz.
|
|
@RJVB Sparc64 has 64-bit
|
|
@RJVB : I have generated a new pull request that includes your fixes but uses <stdint.h> to define uint32_t etc if and only if needed. |
| CHECK_ERR(err, "inflateEnd"); | ||
|
|
||
| if (d_stream.total_out != 2*uncomprLen + comprLen/2) { | ||
| fprintf(stderr, "bad large inflate: %lld\n", d_stream.total_out); |
There was a problem hiding this comment.
if you want to support gcc and clang have to use PRId64 from inttypes.h.
There was a problem hiding this comment.
Would you be happy with:
#include <stdint.h>
#include <inttypes.h>
...
fprintf(stderr, "bad large inflate: %10" PRId64 "\n", d_stream.total_out);
| * upper bound of about 14% expansion does not seem onerous for output buffer | ||
| * allocation. | ||
| */ | ||
| uint64_t ZEXPORT deflateBound(strm, sourceLen) |
There was a problem hiding this comment.
I would really rather keep the uintN_t instead.
There was a problem hiding this comment.
This change is not used/required in the updated PR#11.
|
As we took PR #8, and this is a stale/conflicting PR, I'm going to close it. |
Update references
These are my current fixes for getting zlib/CloudFlare to build on Mac and work as a real drop-in replacement: