[zlib] Bump to upstream 1.2.12

[lambdageek]

Also cherrypick madler/zlib@ec3df00 to restore pre-1.2.12 behavior:

The previous releases of zlib were not sensitive to incorrect CRC
inputs with bits set above the low 32. This commit restores that
behavior, so that applications with such bugs will continue to
operate as before.

Also bump zlib-intel to https://github.com/jtkukunas/zlib/tree/v1.2.12_jtk and cherrypick vanilla zlib crc32 fix (above) tozlib-intel.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Also cherrypick madler/zlib@ec3df00 to restore pre-1.2.12 behavior:

The previous releases of zlib were not sensitive to incorrect CRC
inputs with bits set above the low 32. This commit restores that
behavior, so that applications with such bugs will continue to
operate as before.

Author:	lambdageek
Assignees:	lambdageek
Labels:	area-Infrastructure-libraries
Milestone:	-

[lambdageek]

Do we have a way of keeping track of patches we apply to zlib?

Should we just wait for 1.2.12.1?

[jkotas]

Do we have a way of keeping track of patches we apply to zlib?

Look for the .txt files under https://github.com/dotnet/runtime/tree/main/src/native/external

[am11]

Thanks! Yes the -version.txt files help during such upgrades.

The build errors are upstream issue: madler/zlib#633. We can workaround it (by explicitly adding prototypes in zlib.h) or wait until it is properly fixed in upstream.

Note that in libraries, we use this zlib on Windows arm{64} and zlib-intel on Windows x{86,64}. Could you please try to collect some numbers from dotnet/performance#2152 on Windows arm64 system?

ps - I think plan is to try to replace both implementations with a single copy of nextgen https://github.com/zlib-ng/zlib-ng (which apparently captures optimizations from other two variants and add SIMD sauce on top), validate the performance impact on supported platforms and then switch all platforms to that (currently on Unix libSystem.IO.Compression.Native is linked with system libz; in contrast, brotli is compiled with in-tree sources).

[lambdageek]

The build errors are upstream issue: madler/zlib#633. We can workaround it (by explicitly adding prototypes in zlib.h) or wait until it is properly fixed in upstream.

I think I'd prefer waiting until it's fixed upstream. 1.2.12 seems not fully ready, to be honest. I think a 1.2.12.1 release is probably imminent.

[lambdageek]

Turned off warnings as errors for -Wstrict-prototypes for the zlib sources.

Bumped zlib-intel to v1.2.12_jtk and also cherrypicked the vanilla zlib crc32 fix to zlib-intel (it applied cleanly).

[lambdageek]

32-bit Windows builds are unhappy because of madler/zlib#631 (comment)

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Also cherrypick madler/zlib@ec3df00 to restore pre-1.2.12 behavior:

The previous releases of zlib were not sensitive to incorrect CRC
inputs with bits set above the low 32. This commit restores that
behavior, so that applications with such bugs will continue to
operate as before.

Also bump zlib-intel to https://github.com/jtkukunas/zlib/tree/v1.2.12_jtk and cherrypick vanilla zlib crc32 fix (above) tozlib-intel.

Author:	lambdageek
Assignees:	lambdageek
Labels:	NO-MERGE, area-System.IO.Compression
Milestone:	-

[cmoaciopm]

Latest dotnet runtime 6 is 6.0.5 currently. Can I expect to get zlib bumped to 1.2.12 in coming 6.0.6 release?

[ghost]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.