On 24/03/11 17:17, Eric Blake wrote:
C99 requires realloc(p,0) to either successfully allocate a 0-sized
array (just like malloc(0)) or to return NULL and leave p unchanged.
glibc treats realloc(p,0) like free(p) (as permitted by C89), and using
C99 compliant code would thus result in a
On 03/24/2011 05:52 PM, Bruno Haible wrote:
Is a pointer to an object of size 0 (in the C99 speak) necessarily a
non-null pointer?
Yes.
In C99, malloc(0) has two behaviors, per 7.20.3:
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer
On 03/24/2011 08:47 PM, Eric Blake wrote:
No argument by me if we enforce saner semantics to xrealloc.
What's the saner semantic? One results in double frees, the other in
memory leaks. I think I prefer the latter, but perhaps the best choice
is just to crash...
Paolo
On 03/25/2011 05:59 AM, Paolo Bonzini wrote:
On 03/24/2011 08:47 PM, Eric Blake wrote:
No argument by me if we enforce saner semantics to xrealloc.
What's the saner semantic? One results in double frees, the other in
memory leaks. I think I prefer the latter, but perhaps the best choice
On 03/25/2011 07:57 AM, Paolo Bonzini wrote:
On 03/25/2011 02:53 PM, Eric Blake wrote:
Would anyone object to this patch?
Not me, but it should be documented in capital letters in NEWS...
diff --git i/NEWS w/NEWS
index 767d0ab..d19ac13 100644
--- i/NEWS
+++ w/NEWS
@@ -12,6 +12,10 @@ User
On 03/25/2011 02:53 PM, Eric Blake wrote:
Would anyone object to this patch?
Not me, but it should be documented in capital letters in NEWS...
Paolo
On 03/25/2011 06:53 AM, Eric Blake wrote:
+/* Change the size of an allocated block of memory P to N bytes, with
+ error checking. This version explicitly rejects non-NULL P
+ combined with N of 0, since the GNU realloc semantics of freeing P
+ and returning NULL interfere with the
On 03/24/2011 04:52 PM, Bruno Haible wrote:
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.
I hadn't thought of this argument,
On 03/25/2011 10:07 AM, Paul Eggert wrote:
On 03/24/2011 04:52 PM, Bruno Haible wrote:
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
On 03/25/2011 09:59 AM, Paul Eggert wrote:
On 03/25/2011 06:53 AM, Eric Blake wrote:
+/* Change the size of an allocated block of memory P to N bytes, with
+ error checking. This version explicitly rejects non-NULL P
+ combined with N of 0, since the GNU realloc semantics of freeing P
+
On 03/25/2011 09:31 AM, Eric Blake wrote:
xrealloc(NULL,0) _must_ return malloc(0) rather than blindly returning NULL.
Yes, that makes sense too. Thanks for thinking it through.
The change you just installed causes xrealloc (NULL, 0)
to return realloc (NULL, 0) without failing, which boils
On 03/25/2011 11:40 AM, Paul Eggert wrote:
On 03/25/2011 09:31 AM, Eric Blake wrote:
xrealloc(NULL,0) _must_ return malloc(0) rather than blindly returning NULL.
Yes, that makes sense too. Thanks for thinking it through.
The change you just installed causes xrealloc (NULL, 0)
to return
Hi Eric,
Your reading of C99 is still not convincing.
About the question whether a pointer to an object of size 0 is necessarily
non-NULL:
On one hand, you refer to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n872.htm
which refers to 6.2.6.1.(2), which says:
objects are composed of
On 03/25/2011 12:14 PM, Bruno Haible wrote:
About the question whether a pointer to an object of size 0 is necessarily
non-NULL:
On one hand, you refer to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n872.htm
which refers to 6.2.6.1.(2), which says:
objects are composed of
On 03/25/2011 12:11 PM, Eric Blake wrote:
the only
sane thing left for POSIX to do without invalidating glibc would be to
require that portable applications shall not call realloc(p,0) for
non-NULL p
That sounds unlikely, since POSIX defers to the C standard.
However, POSIX *could* mark
On 03/25/2011 02:21 PM, Paul Eggert wrote:
On 03/25/2011 12:11 PM, Eric Blake wrote:
the only
sane thing left for POSIX to do without invalidating glibc would be to
require that portable applications shall not call realloc(p,0) for
non-NULL p
That sounds unlikely, since POSIX defers to the
C99 requires realloc(p,0) to either successfully allocate a 0-sized
array (just like malloc(0)) or to return NULL and leave p unchanged.
glibc treats realloc(p,0) like free(p) (as permitted by C89), and using
C99 compliant code would thus result in a double-free bug.
POSIX 2008 is ambiguous - it
On 03/24/2011 10:17 AM, Eric Blake wrote:
How should gnulib react? And are there any existing GNU programs that
would break if C99 realloc semantics were enforced?
My kneejerk reaction is that
programs should be written so as to be portable to
both C89 (which GNU implements) and C99 realloc.
Paul Eggert wrote:
On 03/24/2011 10:17 AM, Eric Blake wrote:
How should gnulib react? And are there any existing GNU programs that
would break if C99 realloc semantics were enforced?
My kneejerk reaction is that
programs should be written so as to be portable to
both C89 (which GNU
On 03/24/2011 01:02 PM, Jim Meyering wrote:
It should be fairly easy to write code that is portable
to both C89 and C99 and does not leak, by using free (p) rather
than realloc (p, 0). For example, we could apply the following
patch to xmalloc.c:
We can do whatever we want with xrealloc,
On 03/24/2011 12:47 PM, Eric Blake wrote:
No argument by me if we enforce saner semantics to xrealloc.
No matter what we do it's problematic, but it's
a bit saner if xrealloc's callers can assume GNU behavior,
so I pushed this:
xmalloc: Do not leak if underlying realloc is C99 compatible.
*
Eric Blake wrote:
C99 requires realloc(p,0) to either successfully allocate a 0-sized
array (just like malloc(0)) or to return NULL and leave p unchanged.
glibc treats realloc(p,0) like free(p) (as permitted by C89), and using
C99 compliant code would thus result in a double-free bug.
I'm
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)
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)
Cygwin (a), (c) if OOM
mingw (b)
Bruno
--
In memoriam Óscar Romero
24 matches
Mail list logo
