https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
Here's a simplified version that shows the problem:
typedef __SIZE_TYPE__ size_t;
#define OLD 40
#define NEW 80
#define OFF 10
int
main (void)
{
char *p = __builtin_malloc (OLD);
char *q = 0;
char *dst = p + OFF;
q = __builtin_realloc (p, NEW);
if (q == 0)
__builtin_unreachable ();
if (q != p)
{
p = q;
dst = q + OFF;
}
__builtin_printf ("old size: %zu, new size: %zu, __bdos: %zu\n",
OLD - OFF, NEW - OFF,
__builtin_dynamic_object_size (dst, 0));
}
The problem is when realloc does not result in a different buffer (q == p);
`dst` is left untouched assuming that it's the same object. I doubt if this is
a portable assumption, since the C standard says that value of q (and
consequently dst?) will have become invalid beyond its lifetime, i.e. the
moment it is realloc'd:
6.2.4 Storage durations of objects
...
The value of a pointer becomes indeterminate when the object it points to (or
just past) reaches the end of its lifetime.
...
It just happens so that with the glibc malloc implementation it remains valid
but ISTM that applications should not rely on it.
Jakub, would you concur with this?
