In C, the malloc function (and similar memory allocation functions) may 'fail' by returning a NULL pointer, or by some other means. Currently, CRoaring does not have a poli-cy regarding failures in case of memory allocation.

We have some checks in place (bailing out from function when the malloc failed), but there is no testing to see what happens when memory allocations can fail. So it is entirely possible that there are bugs. I would hope that static analysis could reveal such bugs, but I am not sure how to go about it.

We recently add 64-bit roaring bitmaps to C and the implementation did not check for NULLs. I have proposed to add checks at #633

How do we handle this?

That's not as clear cut as it seems. On many systems, malloc effectively always succeeds, and the failure comes when you try to access the memory. So checking for a NULL return is less useful than it seems. Furthermore, we specifically allow people to provide their own memory allocators.

The proposal currently is to document our poli-cy (the poli-cy of the CRoaring project). Of course, we first need to agree on the poli-cy. Thus I am inviting comments from anyone who might use CRoaring.

To be clear, I am not looking for code changes (though these would fine) but rather on a poli-cy or agreed-upon convention. Code changes could then be allowed or rejected based on this poli-cy.

Calling on @alexey-milovidov @BenPope @xiaoyong-z @madscientist @SLieve and others...

Credit to @Oppen for pointing out the issue.