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 _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
