Tim Ruehsen <[email protected]> writes:
> But after all, you still won't need them. Just have a look in the patched
> hmac-test.c, where you can find are mixtures of hex data and strings.
I haven't read the complete patch very carefully. In hmac-test.c, you
have introduced a flag argument, which is not as clumsy as I had
expected (but I prefer my preprocessor hack before your algorithm enum
and corresponding switch statement; I think it's clear that we have
somewhat different taste).
In other places, you have introduced additional functions, like
test_hash and test_hash_hex. I prefer a style which looks more like
functional programming, with a single test_hash using a canonical
representation of the input, and then the caller invokes any helper
macro or function needed to convert data from whatever form is most
convenient in the test file.
Then I happily admit that the current implementation with macros is not
very beautiful.
> /* example test function with testdata_t */
> void
> test_cipher(const struct nettle_cipher *cipher,
> testdata_t *key,
> testdata_t *cleartext,
> testdata_t *ciphertext)
> {
> // use key.length instead of key_length, etc.
> ...
>
> free(ciphertext);
> free(cleartext);
> free(key);
> }
In this model, we have a producer/consumer convention. The passed in
data is *always* malloced, to be freed by the test function. That's a
good idea, if we now consider deallocation important, that convention
will simplify things (at the cost of an unnecessary allocation in the
few cases where we now pass a string literal as the pointer).
> xmalloc should be slightly changed to not allow size 0 (either fail or
> allocated a 1 byte size).
> From my man pages:
> If size is 0, then malloc() returns either NULL, or a unique pointer value
> that can later be successfully passed to free().
I don't see the problem.
First, it is important to note that callers of xalloc are not expected
to check the return value of xalloc, it will never return NULL except
maybe when size == 0, and in that case it does *not* indicate that
allocation failed. By definition, if xalloc returned, then it did not
fail.
Noow, xalloc is sometimes called with size 0, for example if you do
decode_hex_dup(""). That's why its check for malloc failing also has to
check size. It will succeed (i.e., not abort) no matter which convention
for size == 0 which malloc follows, and simply return whatever malloc
returns.
As far as I see, it doesn't matter if malloc (and hence xalloc) returns
NULL or a valid pointer, in either case, the caller should not
dereference the pointer, and eventually pass it to on to free.
In which way do you think it fails?
Reggards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
