Function GC_realloc 

pub unsafe extern "C" fn GC_realloc(
    arg1: *mut c_void,
    arg2: usize,
) -> *mut c_void

For compatibility with C library. This is occasionally faster than a malloc followed by a bcopy. But if you rely on that, either here or with the standard C library, your code is broken. Probably, it should not have been invented, but now we are stuck. The resulting object has the same kind as the original one. It is an error to have changes enabled for the original object. It does not change the contents of the object from its beginning to the minimum of old size and new_size_in_bytes; the contents above in case of object size growth is initialized to zero (not guaranteed for atomic object type). The function follows ANSI conventions for NULL old_object (i.e., equivalent to GC_malloc regardless of new_size_in_bytes). If new_size_in_bytes is zero (and old_object is non-NULL), then the call is equivalent to GC_free (and NULL is returned). If old_object is non-NULL, it must have been returned by an earlier call to GC_realloc, GC_malloc or friends. In case of the allocation failure, GC_realloc (and its debug variant) does not touch and does not free memory pointed by old_object. The logic of GC_reallocf and its debug variant is different - they free memory pointed by old_object if the allocation has failed. If the returned pointer is not the same as old_object and both of them are non-NULL, then old_object is freed. Returns either NULL (in case of the allocation failure or zero new_size_in_bytes) or pointer to the allocated memory. For a nonzero new_size_in_bytes, the functions are guaranteed never to return NULL unless GC_oom_fn() returns NULL.