On Sat, 2006-02-25 at 10:31 +0000, Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Daniel Berlin wrote:
> > A configure test where we select either the zlib.h version or our
> > version would be silly, because then, in the remote possibility it ever
> > did change, your subversion would break depending on whether you had a
> > new enough zlib around it could pull compressBound from or not.
>
> Uhh, what?
>
> That's not right: If all new versions of zlib supply compressBound,
Well, since we are already arguing about something with a very remote
probability, I will just point out that zlib doesn't have a policy of
providing these API guarantees, so they might disappear on a whim, just
the same as compressBound changing.
> and
> we have a fallback which is correct for the versions which do not,
> then
> we should always be using the correct version.
> This is exactly the kind of situation autoconf is meant for.
>
I still claim it is a complete waste of time in this case, for the other
reasons I've posited.
There is a limit to the amount of defensiveness needed, and i think
anything more than noting where the macro comes from is overkill.
If you want to do it, go for it, i won't stop you :)
You could also simply make the number 13.5% of input size + 11 bytes,
and call it a day, because without changing the algorithm zlib uses in
an incompatible way, that is the absolute worst case you could generate
by toggling the parameters compressBound is using as constants.
See http://www.zlib.net/zlib_tech.html about deflateInit2
Unless you want to also try to protect against zlib making completely
incompatible changes to their format that is used widely and specified
by RFC, plus removing parts of their API, and ....
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 25 15:48:07 2006