Sorry for my slow response...
On 2010年02月13日 16:42, Junio C Hamano wrote:
Hitoshi Mitake<mitake@xxxxxxxxxxxxxxxxxxxxx> writes:
Because strlen(challenge_64) is the upper limit of length of challenge.
So tail part of challenge may not be filled by EVP_DecodeBlock(),
non-zero filled buffer produces not NULL terminated string.
I've confused once by this problem before.
If you know the length of the decoded thing, then you would just know
how much to hash. Doesn't the EVP_DecodeBlock() give you that number?
Why do you need a NUL termination to begin with?
Because you pretend as if you do not have the actual length, you run
strlen() instead. I am not that familiar with the API to EVP_* functions,
but I'd be surprised if it were designed in such a stupid way to force you
to write into a pre-zeroed buffer.
Sorry, what you say is completely correct.
And base64 is not an ascii specific thing, so strlen() cannot provide
correct information here.
Please forgive my foolish coding...
# I tried to reproduce the problem of not NULL terminated case,
# but I could not. I wonder what that was..
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html