Nikos Mavrogiannopoulos <[email protected]> writes:
> On Sun, 2016-07-17 at 12:14 +0200, Niels Möller wrote:
>> I'd like to eliminate pointer-signedness warnings. I'm afraid some
>> ugly
>> casts will have to be involved, since most functions work with
>> uint8_t,
>> and at least test code needs to pass literal strings, of type char *.
I've now gotten rid of most of those warnings, pushing the changes soon.
>> I have one question, on the ascii-armor funtions: Would ie make sense
>> to change the type of ascii inputs and outputs to char? I.e.,
>>
>> size_t
>> base64_encode_update(struct base64_encode_ctx *ctx,
>> - uint8_t *dst,
>> + char *dst,
>> size_t length,
>> const uint8_t *src);
>
> I think it would be good API-wise. I had to casted these parameters in
> almost every use I had for them.
I've given this a try (on a local branch). It makes sense most of the
time. But where are a couple of places where encoding and decoding is
done in-place. Typical example, from the nettle-pbkdf2 command line tool:
salt = (uint8_t *) strdup (argv[0]);
salt_length = strlen(argv[0]);
if (hex_salt)
{
struct base16_decode_ctx base16;
base16_decode_init (&base16);
if (!base16_decode_update (&base16,
&salt_length, salt,
salt_length, salt)
|| !base16_decode_final (&base16))
die ("Invalid salt (expecting hex encoding).\n");
}
This gets a bit awkward with different types for src and dst. Should we
care about this somewhat obscure usecase? Can it be handled in a clean
way?
Regards,
/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
