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
upgrade to newer miniz from mainstream? #270
Comments
OK, will try messing with it tomorrow. |
Someone else appears to have taken over maintaining miniz from Rich Geldreich, and relicensed it to be MIT instead of public domain: So we don't have to add MIT to our license, we'd need to either delete the zip64 code (we only need zlib decompression I assume, not any zip support), or use a version before they were added. |
(To be clear, Rich probably added the zip64 code when personally working on vogl at Valve, not whomever the new person is.) |
OK, I'll cancel this one. There are a lot of warnings from miniz.h ( |
OK, I silenced the majority of the warnings. Only the following are left:
I can silence them by disabling unaligned stores, like the following. OK? diff --git a/IMG_png.c b/IMG_png.c
index b5c6082..6ab0aa7 100644
--- a/IMG_png.c
+++ b/IMG_png.c
@@ -695,6 +695,7 @@ static int IMG_SavePNG_RW_libpng(SDL_Surface *surface, SDL_RWops *dst, int freed
#else
#define MINIZ_LITTLE_ENDIAN 0
#endif
+#define MINIZ_USE_UNALIGNED_LOADS_AND_STORES 0
#define MINIZ_SDL_NOUNUSED
#include "miniz.h"
diff --git a/miniz.h b/miniz.h
index 76f51cb..b213c4e 100644
--- a/miniz.h
+++ b/miniz.h
@@ -230,10 +230,12 @@
#endif
#endif /**/
+#ifndef MINIZ_USE_UNALIGNED_LOADS_AND_STORES
#if MINIZ_X86_OR_X64_CPU
// Set MINIZ_USE_UNALIGNED_LOADS_AND_STORES to 1 on CPU's that permit efficient integer loads and stores from unaligned addresses.
#define MINIZ_USE_UNALIGNED_LOADS_AND_STORES 1
#endif
+#endif /**/
#if defined(_M_X64) || defined(_WIN64) || defined(__MINGW64__) || defined(_LP64) || defined(__LP64__) || defined(__ia64__) || defined(__x86_64__)
// Set MINIZ_HAS_64BIT_REGISTERS to 1 if operations on 64-bit integers are reasonably fast (and don't involve compiler generated calls to helper functions).
A quick solution would be marking all of those with |
For files that we're likely to pull changes from upstream I'd be inclined to minimize changes to make it easy to accept updates in the future. Even for the misleading whitespace changes you made, I'd prefer to silence the warnings using a pragma outside the header or at the top of the header rather than change the affected code sites. If we think fixing the warnings is important, I'd rather submit an upstream PR and cherry-pick that when it's accepted. @icculus, what are your thoughts? |
I think you're right in general, but I'm going to ask the miniz guy if he'll remove the license change if I write the zip64 code from scratch, because this is a dumb thing to have to workaround in the first place. |
Why do we even need the zip64 code in the first place?? I think my first instinct about cancelling the upgrade to new miniz was right: We don't |
I pushed the As for stb_image: Waiting your decisions. (BTW: our stb_image is behind mainstream, |
We don't; but if that's why they changed the license, it would be nice to get it back to public domain so we don't have to maintain a fork. |
Mainstream miniz received many updates: Do we want to upgrade?
Similar question for nanosvg, which we have two or three commits missing
compared to mainstream.
The text was updated successfully, but these errors were encountered: