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 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);
and similarly for all related functions. It would be an API change but not an ABI change for any ABI spec I'm aware of. What do you think? So the input to encoding is an octet string (uint8_t), and the output is a string of plain char. And vice versa for decoding functions.
Also applies to the type arguments for sexp_iterator_check_type, sexp_iterator_check_types and sexp_iterator_assoc, currently using uint8_t. They are usually called with literal ascii strings, so it would make some sense to type as char rather than uint8_t. (I don't think these are used much by any application except lsh and libspki).
And no matter how things are typed, I wouldn't expect nettle to work out of the box on platforms where char and uint8_t are of different size, or where string literals use a non-asciii character set.
Regards, /Niels
On 17/07/2016 10:14 p.m., 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 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);and similarly for all related functions. It would be an API change but not an ABI change for any ABI spec I'm aware of. What do you think? So the input to encoding is an octet string (uint8_t), and the output is a string of plain char. And vice versa for decoding functions.
As one user of these functions from nettle it is only long-term gain. We already have nasty casting to get from char to uint8_t at our end. In the 5yr-10yr short term we still need to support older libraries API, so that annoyance wont disappear for a long while. It is only a minor change to convert with a helper macro or function though.
Our uses of nettle are Base-64 and MD5 currently. With SHA and AES on the semi-distant horizon. The remaining crypto done indirectly through GnuTLS.
Amos
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 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.
not an ABI change for any ABI spec I'm aware of. What do you think?
As long as it doesn't break the ABI it's good to have such changes. It's less code to type to use these functions.
btw. Would you be interested in a patch which adds automatic x86-64 abi check via the CI? Something like:
https://gitlab.com/gnutls/gnutls/commit/99b4b7bb53f6d36ee991e2a2679776faf433...
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
nettle-bugs@lists.lysator.liu.se
-
Amos Jeffries -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se