On Mon Jul 11 16:20:29 2016, k...@roeckx.be wrote: > Hi, > > When trying to check what happens if we simulate malloc() > returning NULL I'm running into a problem that I'm not sure how to > deal with. > > We have CRYPTO_THREAD_run_once(), which takes an init() function > that returns void, so it can't return failures. At least the > pthread_once() function also has it as void. > > But if those functions call malloc() and that returns NULL, we now > don't catch that error, and later just try to use a NULL pointer. > > Anybody a good idea how to solve this?
Rethinking this... Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first locks, so pretty much in an initial state of the library (not entirely true, since we do these inits opportunistically, but it's probable that they happen very early on). If they are having memory allocation, the running app is probably in deep shit anyway, so a hard assert in our diverse inits would probably be appropriate either way. It was suggested that we change the return type of the init routine to int and have it return something appropriate (0 for error, 1 for success, say?), but since at least pthread_once() takes a function returning void (and thereby doesn't care about any returned value), it seems like our hands are forced anyway. -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
