You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ASSERT_ALLOC(p, n) allocates room for nelements, not bytes. Its core is p = calloc(sizeof(*p), n). But we've been using it wrong, e.g. #6419 and in recent bignum core tests. After discussion, we've decided to rename the macro to xxx_CALLOC so that it's less error-prone.
The goal of this issue is to investigate and fix the existing usage, i.e. look for and fix places where the pointer is to a non-byte-sized type and the size is expressed in bytes rather than elements. We can identify the places where the element size is not 1 by tweaking the definition of ASSERT_ALLOC and causing a build failure (or probably, with GCC exensions, a warning) when the size is not 1.
This is likely to conflict with #6421 so they should either be done together or sequentially, not in parallel. It would probably be best to do #6421 first, then wait a bit until there is no more work in flight that uses the old name, and then fix the remaining usage and remove the old error-prone name.
The text was updated successfully, but these errors were encountered:
ASSERT_ALLOC(p, n)
allocates room forn
elements, not bytes. Its core isp = calloc(sizeof(*p), n)
. But we've been using it wrong, e.g. #6419 and in recent bignum core tests. After discussion, we've decided to rename the macro toxxx_CALLOC
so that it's less error-prone.The goal of this issue is to investigate and fix the existing usage, i.e. look for and fix places where the pointer is to a non-byte-sized type and the size is expressed in bytes rather than elements. We can identify the places where the element size is not 1 by tweaking the definition of
ASSERT_ALLOC
and causing a build failure (or probably, with GCC exensions, a warning) when the size is not 1.This is likely to conflict with #6421 so they should either be done together or sequentially, not in parallel. It would probably be best to do #6421 first, then wait a bit until there is no more work in flight that uses the old name, and then fix the remaining usage and remove the old error-prone name.
The text was updated successfully, but these errors were encountered: