On Mon, May 14, 2018 at 11:17:51AM +0200, Michal Privoznik wrote:
On 05/11/2018 05:50 PM, Ján Tomko wrote:
> A function that keeps the hash in binary form instead of converting
> it to human-readable hexadecimal form.
>
> Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
> ---
> src/util/vircrypto.c | 31 +++++++++++++++++++++----------
> src/util/vircrypto.h | 7 +++++++
> 2 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/src/util/vircrypto.c b/src/util/vircrypto.c
> index 48b04fc8ce..1a2dcc28b7 100644
> --- a/src/util/vircrypto.c
> +++ b/src/util/vircrypto.c
> @@ -54,28 +54,39 @@ struct virHashInfo {
> verify(ARRAY_CARDINALITY(hashinfo) == VIR_CRYPTO_HASH_LAST);
>
> int
> -virCryptoHashString(virCryptoHash hash,
> - const char *input,
> - char **output)
> +virCryptoHashBuf(virCryptoHash hash,
> + const char *input,
> + unsigned char *output)
> {
> - unsigned char buf[VIR_CRYPTO_LARGEST_DIGEST_SIZE];
> - size_t hashstrlen;
> - size_t i;
> -
> if (hash >= VIR_CRYPTO_HASH_LAST) {
> virReportError(VIR_ERR_INVALID_ARG,
> _("Unknown crypto hash %d"), hash);
> return -1;
> }
This check feels useless. It's like if we were checking a value before
passing it to vir*TypeToString(). But it's pre-existing, so you have my
ACK. But a follow up patch removing it (=trivial) would be nice.
On one hand, this check should be pointless if the rest of our code is
correct.
On the other hand, our functions in src/util usually do perform some
validation of the parameters. Although it could be transformed to use
virReportEnumRangeError.
Also, don't forget to export the symbol in libvirt_private.syms ;-)
I'm wondering how linker succeeds in 3/5 where you use the function
without it being exported. Maybe my compiler decided to inline this
function?
Thanks, fixed.
Jano
Michal