is big-endian compatible ? about junzip

[jokkebk]

I haven't tested them on those. It depends how file reading operations and such arrange uint32_t and similar multibyte variables. One would need to run the code and see if the signature check against 0x02014B50 in the code works, and if file offsets, sizes etc. work correctly. Unfortunately I don't have access to big-endian systems at the moment.

[denisdemaisbr]

some properties of file header need converstion on big-endian systems.
i will try test and report you

system: arm32 big endian

[PerBothner]

A possible solution is to use <endian.h>. For example in jzReadLocalFileHeader instead of:

memcpy(header, &localHeader.compressionMethod, sizeof(JZFileHeader));

write:

header->compressionMethod = le16toh(localHeader.compressionMethod);
header->lastModFileTime = le16toh(localHeader.lastModFileTime);

and so on. Of course this conversion must be done before any of the values are actually used.

A disadvantage is that <endian.h> isn't very portable - but the existing code isn't very portable anyway, as it requires __attribute__ ((__packed__)). The macros in <endian.h> should be pretty efficient.

[PerBothner]

For DomTerm I started with JUnzip, but re-wrote it pretty extensively. It should now be more portable, and I expect no byte-order problems. It is also simpler and faster, by using a simplifying assuming that the entire zip file is mmap'd into memory. See files lws-term/junzip.h and lws-term/junzip.c in the GitHub source code.

[jokkebk]

@PerBothner very nice. :) I would suggest contributing changes back to JUnzip, but this is in no way an active project for me at the moment, so I'll leave this issue "open" for others to see. For same reason, I think endianness remains somewhat x86 centric for the time being, unless someone submits a pull request I can make sense of. 😄