[EMAIL PROTECTED] writes:
> -> We have md5's, md4's, sha1, et.al.
> The all have this structure.
Just talking about the interfaces in apr_md5.h.
Anyway, unless someone is using a vtable to choose which checksum
function to use (?), it shouldn't matter that other interfaces do have
return values. (Of course, if they also can safely be void, then they
should be.)
> -> I can easily imagine an init of sorts to need to be
> able to flag an error at some point.
I can't imagine it, to be honest. It's initializing an in-memory
structure of known size, using static values, and it's not checking
the prior values in the structure. Therefore, there's no possible
error that we could detect (the structure could be too small, but
that's a segfault, not a catchable error).
MD5 is pretty well settled; I don't see this stuff changing
significantly. :-)
> -> This is quite an API change - soon after products
> which rely on it have gone GA. Which is a patent
> way to get breakage - and I seen o compelling need
> for the systems in production today. I guess we need
> a fork/branching and versioning story there.
Just curious, what's "GA" stand for?
This isn't urgent. If people don't want to branch, and prefer to wait
until Apache 2.0 is out the door, that's fine. But the longer we
wait, the higher the cost:
- More callers out there, cluttering up their code with meaningless
return value checks,
- More wasted time as puzzled developers (like me) delve into the
APR sources to see whether they really need to care about these
return values, only to discover that their initial hunch was
right -- they don't.
So I would like to fix it sooner or later, though don't want to cause
the Apache team trouble.
-K
