* [PATCH RFA #2] utils.c: Fix xcalloc (0, 0) behavior
@ 2001-03-05 16:06 Kevin Buettner
2001-03-05 17:11 ` Kevin Buettner
2001-03-06 14:27 ` Andrew Cagney
0 siblings, 2 replies; 3+ messages in thread
From: Kevin Buettner @ 2001-03-05 16:06 UTC (permalink / raw)
To: gdb-patches
The patch below supercedes the patch that I submitted in
http://sources.redhat.com/ml/gdb-patches/2001-03/msg00052.html
The patch below is much more aggressive in that it will cause NULL to
be returned for *all* platforms when a zero-sized request is made to
one of GDB's memory allocation functions. The patch in the message
referenced above only returned NULL when the underlying allocation
functions (upon which GDB's are implemented) chose to return NULL. I
think the consensus opinion is that it would be better to make the
behavior consistent across platforms so that bugs will be caught
sooner.
I have tested this patch on i386-unknown-freebsd4.2 and
i686-pc-linux-gnu and do not see any regressions.
* utils.c (xmrealloc, xcalloc): Return NULL for zero-sized requests.
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.31
diff -u -p -r1.31 utils.c
--- utils.c 2001/02/25 04:45:11 1.31
+++ utils.c 2001/03/05 23:24:05
@@ -1042,18 +1042,27 @@ xmrealloc (PTR md, PTR ptr, long size)
{
register PTR val;
- if (ptr != NULL)
+ if (size == 0)
{
- val = mrealloc (md, ptr, size);
+ if (ptr != NULL)
+ mfree (md, ptr);
+ val = NULL;
}
else
{
- val = mmalloc (md, size);
+ if (ptr != NULL)
+ {
+ val = mrealloc (md, ptr, size);
+ }
+ else
+ {
+ val = mmalloc (md, size);
+ }
+ if (val == NULL)
+ {
+ nomem (size);
+ }
}
- if (val == NULL)
- {
- nomem (size);
- }
return (val);
}
@@ -1071,9 +1080,16 @@ xmalloc (size_t size)
PTR
xcalloc (size_t number, size_t size)
{
- void *mem = mcalloc (NULL, number, size);
- if (mem == NULL)
- nomem (number * size);
+ void *mem;
+
+ if (number == 0 || size == 0)
+ mem = NULL;
+ else
+ {
+ mem = mcalloc (NULL, number, size);
+ if (mem == NULL)
+ nomem (number * size);
+ }
return mem;
}
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RFA #2] utils.c: Fix xcalloc (0, 0) behavior
2001-03-05 16:06 [PATCH RFA #2] utils.c: Fix xcalloc (0, 0) behavior Kevin Buettner
@ 2001-03-05 17:11 ` Kevin Buettner
2001-03-06 14:27 ` Andrew Cagney
1 sibling, 0 replies; 3+ messages in thread
From: Kevin Buettner @ 2001-03-05 17:11 UTC (permalink / raw)
To: gdb-patches
On Mar 5, 5:06pm, Kevin Buettner wrote:
> I have tested this patch on i386-unknown-freebsd4.2 and
> i686-pc-linux-gnu and do not see any regressions.
>
> * utils.c (xmrealloc, xcalloc): Return NULL for zero-sized requests.
Another data point: I've just tested this patch on sparc-sun-solaris2.7
and all's well...
Kevin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RFA #2] utils.c: Fix xcalloc (0, 0) behavior
2001-03-05 16:06 [PATCH RFA #2] utils.c: Fix xcalloc (0, 0) behavior Kevin Buettner
2001-03-05 17:11 ` Kevin Buettner
@ 2001-03-06 14:27 ` Andrew Cagney
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2001-03-06 14:27 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
How ironic :-)
Go to all this effort to get everything using a function that doesn't
return NULL only to find that we need to go to even more effort so that
it can return NULL. Ha!
One aside. From memory, the asprintf() functions in ../libiberty tend
to not like:
asprintf ("%s", NULL);
giving either:
(null)
or Segmentation Fault, Core dumped.
I submitted a patch to make the behavour but had it rejected.
The thing I would take from this is that we've a GDB convention.
Getting these specific semantics merged into ../libiberty is separate.
M'kay with me. Anyone?
Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-03-06 14:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-05 16:06 [PATCH RFA #2] utils.c: Fix xcalloc (0, 0) behavior Kevin Buettner
2001-03-05 17:11 ` Kevin Buettner
2001-03-06 14:27 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox