Simon Josefsson <[email protected]> writes: > Collin Funk <[email protected]> writes: > >> Second, I used xalloc-die as a conditional dependency. This is because >> the EVP functions are documented as returning 0 on failure. In practice, >> I can only see this being the case for EVP_MD_CTX_create, but that >> should be rare (e.g. OOM). I would rather not change the prototypes to >> be different than the other digests in Gnulib, so there is no way to >> return errors back to the caller. This shouldn't matter for Coreutils, >> but calling abort in libraries is not great, in my opinion. Using >> xalloc_die is only slightly more friendly. > > I think this is deeply problematic -- I haven't needed SHA3 in any > library so far, but it is a question of time. And libraries shouldn't > have to use gnulib's xalloc-die. What is the actual problem here? Is > it that the gnulib APIs doesn't provide a way to signal an error, but > the OpenSSL API have it? Then I think we should modify the gnulib API > to be able to signal an error. That seems like the proper solution to > me, even if error handling often is a pain.
Ideally OpenSSL would provide the typical low-level digest API so you could allocate the context on the stack and use them. My later patch allocates it on the stack, so it will only abort through programmer error (e.g. calling sha3_update without calling sha3_init). Maybe I can change them all return int/bool later, but it will require some work. At least Emacs uses them through a function pointer. Collin
