-
-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add public compile definition for zlib-ng API #1292
Add public compile definition for zlib-ng API #1292
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1292 +/- ##
========================================
Coverage 86.57% 86.58%
========================================
Files 124 124
Lines 10533 10537 +4
Branches 2622 2624 +2
========================================
+ Hits 9119 9123 +4
+ Misses 1059 1058 -1
- Partials 355 356 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
@Dead2 any thoughts on the #define naming? |
|
…that use CMake and link against the zlib project can easily determine whether or not to include "zlib-ng.h" or "zlib.h".
5268063
to
289a2b1
Compare
I perfer |
Changes since 2.0.6: - Fix CVE-2022-37434 #1328 - Fix chunkmemset #1196 - Fix deflateBound too small #1236 - Fix Z_SOLO #1263 - Fix ACLE variant of crc32 #1274 - Fix inflateBack #1311 - Fix deflate_quick windowsize #1431 - Fix DFLTCC bugs related to adler32 #1349 and #1390 - Fix warnings #1194 #1312 #1362 - MacOS build fix #1198 - Add invalid windowBits handling #1293 - Support for Force TZCNT #1186 - Support for aligned_alloc() #1360 - Minideflate improvements #1175 #1238 - Dont use unaligned access for memcpy #1309 - Build system #1209 #1233 #1267 #1273 #1278 #1292 #1316 #1318 #1365 - Test improvements #1208 #1227 #1241 #1353 - Cleanup #1266 - Documentation #1205 #1359 - Misc improvements #1294 #1297 #1306 #1344 #1348 - Backported zlib fixes - Backported CI workflows from Develop branch
Changes since 2.0.6: - Fix CVE-2022-37434 #1328 - Fix chunkmemset #1196 - Fix deflateBound too small #1236 - Fix Z_SOLO #1263 - Fix ACLE variant of crc32 #1274 - Fix inflateBack #1311 - Fix deflate_quick windowsize #1431 - Fix DFLTCC bugs related to adler32 #1349 and #1390 - Fix warnings #1194 #1312 #1362 - MacOS build fix #1198 - Add invalid windowBits handling #1293 - Support for Force TZCNT #1186 - Support for aligned_alloc() #1360 - Minideflate improvements #1175 #1238 - Dont use unaligned access for memcpy #1309 - Build system #1209 #1233 #1267 #1273 #1278 #1292 #1316 #1318 #1365 - Test improvements #1208 #1227 #1241 #1353 - Cleanup #1266 - Documentation #1205 #1359 - Misc improvements #1294 #1297 #1306 #1344 #1348 - Backported zlib fixes - Backported CI workflows from Develop branch
This is so that other projects that use CMake and link against the zlib project can easily determine whether or not to include "zlib-ng.h" or "zlib.h". They would do this in order to support zlib compatibility.I am open to the different naming.
Any consumer project that uses
target_link_libraries(${PROJECT_NAME} zlibstatic)
(zlib or zlibstatic) can use:They would do this in order to also support zlib compatibility. https://github.com/zlib-ng/minizip-ng/blob/47b8449fec2c7a575a506ecbe6399ad0603b5992/mz_strm_zlib.c#L16