Hi Collin,
> But now I realize that we cannot use xalloc_die
> here. I just noticed the following:
>
> $ gnulib-tool --create-testdir --dir testdir1 crypto/sha3
> gnulib-tool: warning: module crypto/sha3 depends on a module with an
> incompatible license: xalloc-die
>
> I rather keep the module LGPL like the rest of the crypto modules.
> Therefore, a call to abort will have to do.
I disagree here. The difference between GPL and LGPL modules is not only
about license, it's also about the situation in which a module can be used:
- Modules under GPL are meant to be used in programs.
- Modules under LGPL are meant to be used in libraries or programs.
In out-of-memory situations:
- Libraries should not abort().
- Programs should call xalloc_die(), not abort().
abort() means "here is a situation that the programmer has not foreseen";
it is not the adequate action upon an out-of-memory situation.
(We have had this distinction between abort() and xalloc_die() for
over 25 years. It really is solid and good.)
If you say "I rather keep the module LGPL", you must avoid the abort().
Technically I see at least two ways to do so:
* Change the API so that the responsibility for calling xalloc_die()
is with the caller. Or
* Allocate the ctx->evp_ctx not via malloc, but on the stack. You can
use a conservative estimate. For instance, if EVP_MD_CTX_create ()
would allocate 217 bytes via malloc(), you can allocate 512 bytes
on the stack and be sufficiently certain that this be enough for
all future evolutions of OpenSSL / EVP.
(Other libraries use the same trick as well. For instance, FreeBSD
has an mbstate_t that is 128 bytes large — fixed but sufficient for
all practical purposes. Or GNU libiconv, which has a type
'iconv_allocation_t' that is opaque but large enough for stack
allocations.)
Bruno
