On 11/03/15 at 09:50pm, Allan McRae wrote:
On 02/11/15 11:41, Andrew Gregory wrote:
If given size 0 POSIX allows realloc to return a pointer that is not suitable for use.
From malloc(3):
"if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr)."
Is that not generally guaranteed? Or is qsort the issue here?
That is not guaranteed, from realloc(3p): Upon successful completion, realloc() shall return a pointer to the (possibly moved) allocated space. If size is 0, either: * A null pointer shall be returned and errno set to an implementation-defined value. * A unique pointer that can be successfully passed to free() shall be returned, and the memory object pointed to by ptr shall be freed. The appli‐cation shall ensure that the pointer is not used to access an object. In fact, malloc(3) doesn't even seem to be accurate for glibc as valgrind still complains about a 0 byte block being lost: └➤ valgrind /bin/pacman -Fl ca-certificates ==1877== Memcheck, a memory error detector ==1877== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1877== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==1877== Command: /bin/pacman -Fl ca-certificates ==1877== ==1877== ==1877== HEAP SUMMARY: ==1877== in use at exit: 0 bytes in 1 blocks ==1877== total heap usage: 103,653 allocs, 103,652 frees, 16,949,886 bytes allocated ==1877== ==1877== LEAK SUMMARY: ==1877== definitely lost: 0 bytes in 1 blocks ==1877== indirectly lost: 0 bytes in 0 blocks ==1877== possibly lost: 0 bytes in 0 blocks ==1877== still reachable: 0 bytes in 0 blocks ==1877== suppressed: 0 bytes in 0 blocks ==1877== Rerun with --leak-check=full to see details of leaked memory ==1877== ==1877== For counts of detected and suppressed errors, rerun with: -v ==1877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) apg