[Zlib-devel] crc32 big/little endian
Joakim Tjernlund
joakim.tjernlund at transmode.se
Wed Apr 21 13:58:03 EDT 2010
>
> 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.
Missing symbols could be a compile failure or one could fall back on the
current way iff __BYTE_ORDER is missing.
>
> > 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.)
non viewing of the archives hardly qualifies as SPAM protection. You don't see that
zlib development looks almost dead to the causal reader? There is nothing
on the home page that indicates that there is ongoing development other
that the releases which can be very far apart(or at least hard to find)
>
> > - 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/
There is no repo and how am I supposed to know about them before I have joined
the list and you have told me?
>
> 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.
Probably not, but an viewable archive would let me search for stuff
if I wanted to and I could see if the project is still alive.
>
> 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.
Here is an example:
Delivery Failure Report
Your message: decompression lenth?
was not delivered to: madler at alumni.caltech.edu
because: 550 5.7.1 <madler at alumni.caltech.edu>: Recipient address rejected: Message rejected due to: SPF fail - not authorized. Only mail.alumni.caltech.edu is authorized to send mail with @alumni.caltech.edu FROM: addresses
What should you do?
You can resend the undeliverable document to the recipients listed above by choosing the Resend button or the Resend command on the Actions menu.
Once you have resent the document you may delete this Delivery Failure Report.
If resending the document is not successful you will receive a new failure report.
Unless you receive other Delivery Failure Reports, the document was successfully delivered to all other recipients.
sesr04/Transmode
To: zlib at gzip.org
cc:
Date: 2009/11/09 18:32:31
Subject: decompression lenth?
Trying to optimize the decomression in zlib and I have a question or two. So far
I have managed to speed up pure direct copy case with more than 10%.
In inffast.c there are this segment(I have embedded the questions):
if (write == 0) { /* very common case */
from += wsize - op;
if (op < len) { /* some from window */
len -= op;
do {
PUP(out) = PUP(from);
} while (--op);
from = out - dist; /* rest from output */
Can one assume min len == 3 here, like the direct copy case that follows this segment?
}
}
else if (write < op) { /* wrap around window */
from += wsize + write - op;
op -= write;
if (op < len) { /* some from end of window */
len -= op;
do {
PUP(out) = PUP(from);
} while (--op);
from = window - OFF;
if (write < len) { /* some from start of window */
op = write;
len -= op;
do {
PUP(out) = PUP(from);
} while (--op);
from = out - dist; /* rest from output */
ditto.
}
}
}
else { /* contiguous in window */
from += write - op;
if (op < len) { /* some from window */
len -= op;
do {
PUP(out) = PUP(from);
} while (--op);
from = out - dist; /* rest from output */
ditto.
}
}
Can one assume a min len when you reach here?
Regards
Joakim Tjernlund
>
> > 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.
Then zlib should be more visible. An outsider is someone who just joined and
have no clue how zlib development is supposed to work.
>
> > 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.
BTW, one can make NOBYFOUR version more efficient but(see what is in the linux kernel)
but one has to know the endian just like the BYFOUR method
>
> 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
More information about the Zlib-devel
mailing list