[pacman-dev] [PATCH] ensure realloc has a positive size

[Andrew Gregory]

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