[Zlib-devel] crc32 big/little endian

[Mark Adler]

On Apr 21, 2010, at 9:51 AM, Joakim Tjernlund wrote:
> Surely there must be some other symbols then for OS X?

So then we have to search those out for every single platform, some of which won't have them.  I am entirely unconvinced that detection at compile time is a better approach.  It certainly isn't as reliable.

> You don't seem to see it that way, instead you seem to hide zlib development from the rest
> of the world:
> - one cannot view the devel email archives or post unless one is a member

To protect members from spam.  I was asked to make it this way.  Anyone can become a member by subscribing and simply responding to a question.  (I accept everyone who responds, no matter the response, unless they say they changed their mind when they saw what the list is for.)

> - There is no repo were one can see the latest development.

http://zlib.net/current/beta/ and the complete history in http://zlib.net/fossils/

You don't even need to be on the list to see those.

> - There is no archive that I can find of zlib at gzip.org, posting there one
>   gets a bounce message back from you.

No, there is no archive.  Believe me, you don't want to deal with all the utterly clueless email I get there.

Bounce message?  Can you send me an example?  I get several emails a day on that email address, so it seems to work fine for a lot of other people.

> So one begs to wonder if you really want help from outsiders like me

zlib is *critically* dependent on help from people like you.  (What is an "outsider" in this context?)  Just because I may disagree with you on some point doesn't mean I don't want and need your help.

> but then again, embedded systems
> doesn't seem to be something you are interested in.

I am interested in supporting all systems.  I would consider adding more defines to help users of those systems control memory usage.  Again, my recommendation on those systems would not be to go from 16K to 8K, but rather they should go all the way to 2K (or 1K if 32-bit integers) by using the NOBYFOUR define, which is why it's there.

My other objective is for zlib to work on *all* systems.  In my opinion, the memory penalty is very small to assure reliability in this case, and there is a define to assure the same reliability with a much smaller table.

Mark