Recent releases of glibc don't include the full stdint.h header in some
network headers included by utils.h. So uintptr_t might not be defined.
Since we use fixed width integers, including the latter, all over the place
we make sure the complete file is included.
Fixes#2425.
While we could use posix_memalign(3), that is not fully portable. Further, it
might be difficult on some platforms to properly catch it in leak-detective,
which results in invalid free()s when releasing such memory.
We instead use a simple wrapper, which allocates larger data, and saves the
padding size in the allocated header. This requires that memory is released
using a dedicated function.
To reduce the risk of invalid free() when working on corrupted data, we fill up
all the padding with the padding length, and verify it during free_align().
These wrappers guarantee that calls to these functions are noops if the
number of bytes is 0, as calling them with NULL pointers is undefined
according to the C standard, even if the number of bytes is 0 (most
implementations probably ignore the pointers anyway in this case, but
lets make sure).
Using the same mechanism as the METHOD macro, the CALLBACK macro defines
a hybrid function signature. It strictly uses a weak void* for the first
function parameter, in contrast to the dynamic METHOD object "this" type.
This solves a problem with GNAT when compiling charon-tkm as __atomic*
built-ins are only provided in GCC 4.7 and newer.
Currently GNAT 4.6 and GCC 4.7.2 is shipped with Debian wheezy (stable),
as used in the testing environment. So while the configure script correctly
detected the __atomic* built-ins, and defined HAVE_GCC_ATOMIC_OPERATIONS,
this define turned out to be incorrect when charon-tkm was later built
with GNAT.
These are available since GCC 4.7 and will eventually replace the __sync
operations. They support the memory model defined by C++11. For instance,
by using __ATOMIC_RELAXED for some operations on the reference counters we
can avoid memory barriers, which are required by __sync operations (whose
memory model essentially is __ATOMIC_SEQ_CST).
On many architectures it is safe to read the value directly (those
using cache coherency protocols, and with atomic loads for 32-bit
values) but it is not if that's not the case or if we ever decide to
make refcount_t 64-bit (load not atomic on x86).
So make sure the operation is actually atomic and that users do not
have to care about the size of refcount_t.
Martin Willi