Corentin Labbe <[email protected]> writes: > Speed is not really a topic for me, I just need them for emulation. > So I am totally fine with > ALGONAME_compress(uint32_t *state, const uint8_t *data)
Sounds good. > But I think the compress_n version could be provided in parallel and > still usefull for my case. If there's no compelling use case, I think it's best to not include compress_n functions in the public api. > So basicly, do you agree if I resent my patch by simply removing all > nettle_ prefix ? Yes, they should use similar name manging as other public functions, referred to as sha256_compress in the sources, and a #define sha256_compress nettle_sha256_compress in the header file. Please also delete the COMPRESS macros in sha256.c and sha512.c, and use the new function instead (I'd expect use within the same source file will typically be inlined). Basic docs (to go in nettle.texinfo) is also appreciated. Additional tests probably not needed, if the code is exercised by the existing tests. > Then a second patch adding sha_compress/md5_compress (But I dont know > if you want and how to deprecate old nettle_md5_compress and such) They should follow the same naming and name mangling as the new functions, except that the aliases with _nettle prefix should be kept for backwards compatibility. > And a third patch adding all compress_n functions. I'm not convinced public compress_n functions will be useful enough to motiviate the larger api (and I imagine they will cause some additional complexity when we get to have optional assembly implementation of those functions). Let's leave out for now. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
