Nikos Mavrogiannopoulos nmav@redhat.com 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