Skip to content

Conversation

@bentley
Copy link
Contributor

@bentley bentley commented Feb 25, 2015

The zip code uses 64-bit fopen(), etc by calling fopen64() and (on
platforms that don't have it) #define-ing fopen fopen64.

But this is redundant. glibc is just about the only libc out there that
needs a separate fopen64(), etc—most C libraries, including other Linux
C libraries, simply use a 64-bit off_t. glibc can do this too, by
compiling programs with _FILE_OFFSET_BITS=64. And the zip code does this.

The zip code uses 64-bit fopen(), etc by calling fopen64() and (on
platforms that don't have it) #define-ing fopen fopen64.

But this is redundant. glibc is just about the only libc out there that
needs a separate fopen64(), etc--most C libraries, including other Linux
C libraries, simply use a 64-bit off_t. glibc can do this too, by
compiling programs with _FILE_OFFSET_BITS=64. And the zip code does this.
@ghost
Copy link

ghost commented Feb 25, 2015

Why not sending this first to https://github.com/madler/zlib and the importing the new version in mupen64plus-core?

@Narann
Copy link
Member

Narann commented Feb 26, 2015

Hi @bentley. I have the impression you are not on the good project. :)

From what I see, you should PR this project first. Once it's done and minizip release a stable version, it could be interesting for us to update to this stable version.

Sorry but I'm not sure this will be ever merged. Any idea @richard42?

@bentley
Copy link
Contributor Author

bentley commented Feb 27, 2015

I’ll push it to the various upstreams. But since the details leak through to the Unix makefile, it is worth bringing up here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants