Eric Blake asked: > How should gnulib react? And are there any existing GNU programs that > would break ...?
There are three possible behaviours of realloc(p,0): (a) returns non-NULL pointer. (b) returns NULL and frees p. (c) fails and returns NULL. Situation per platform: glibc (b) FreeBSD (a), (c) if OOM OpenBSD (a), (c) if OOM AIX (b) HP-UX (b) IRIX (a), (c) if OOM OSF/1 (b) Solaris (b) So, code which calls realloc(p,0) and does not free p if that returns NULL works OK on glibc, AIX, HP-UX, OSF/1, Solaris, but leaks memory in case of out-of-memory on BSD, IRIX. Whereas code which calls realloc(p,0) and frees p if that returns NULL works OK on BSD, IRIX, but crashes on glibc platforms and leads to subtle memory bugs on AIX, HP-UX, OSF/1, Solaris. - Argue like this: There's no way to do it right. Therefore I think gnulib should encourage programmers to avoid calling realloc(p,0) at all. I propose to add a new module 'realloc-safe' which emits a diagnostic and then calls abort() if realloc(p,0) is called. - Or argue like this: Leaking memory when you are already out of memory is not a problem: the program will need to terminate very soon anyway. So code which calls realloc(p,0) and does not free p if that returns NULL is just fine. Which argumentation do you prefer? Bruno -- In memoriam Óscar Romero <http://en.wikipedia.org/wiki/Óscar_Romero>
