10 Sep
2015
10 Sep
'15
7:52 p.m.
I’ve just had a discussion with my boss about this and he claimed that it did at one point
and I said it hasn’t in all the unix versions I’ve ever played with (v6, v7, sys III, V,
BSD 2, 3, 4, SunOS and Solaris).
My question to this illustrious group is: Did any Unix or Unix like OS ever zero fill on
realloc?
David
10 Sep
10 Sep
8:10 p.m.
On every system that I've ever used, I believe that realloc did not do a zero fill.
There might have been a time when malloc did a zero fill, but I never counted on it. I
always performed a memset or bzero after a malloc. I'm pretty sure that I counted on
realloc to NOT perform a zero fill.
$.02
From: "David" <david(a)kdbarto.org>
To: tuhs(a)minnie.tuhs.org
Sent: Thursday, September 10, 2015 3:52:45 PM
Subject: [TUHS] Did realloc ever zero the new memory?
I’ve just had a discussion with my boss about this and he claimed that it did at one point
and I said it hasn’t in all the unix versions I’ve ever played with (v6, v7, sys III, V,
BSD 2, 3, 4, SunOS and Solaris).
My question to this illustrious group is: Did any Unix or Unix like OS ever zero fill on
realloc?
David
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
8:22 p.m.
Buggy, sure.
Zero (less) filling, that is the question.
Realloc has had a difficult history, and I try to avoid it if at all possible.
David
On Sep 10, 2015, at 1:21 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Am I the only one that remembers realloc() being buggy on some systems?
8:27 p.m.
Good, glad to know it wasn't just me. I've finally let my team use it
but we avoided it when we supported more odd ball platforms.
On zero fill, I doubt many did that. Many really early on when memory
was small.
What you might be thinking of is modern systems implement malloc()
as an mmap of /dev/zero and the initial data comes through as zeroed.
But counting on that would be a mistake.
On Thu, Sep 10, 2015 at 01:22:33PM -0700, David wrote:
Buggy, sure.
Zero (less) filling, that is the question.
Realloc has had a difficult history, and I try to avoid it if at all possible.
David
> On Sep 10, 2015, at 1:21 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
>
> Am I the only one that remembers realloc() being buggy on some systems?
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
8:29 p.m.
I mentioned the /dev/zero malloc and, no, he was quite sure that it was realloc doing the
zero fills.
Glad to know that I’m sitting on the right side of history on this one.
David
On Sep 10, 2015, at 1:27 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Good, glad to know it wasn't just me. I've finally let my team use it
but we avoided it when we supported more odd ball platforms.
On zero fill, I doubt many did that. Many really early on when memory
was small.
What you might be thinking of is modern systems implement malloc()
as an mmap of /dev/zero and the initial data comes through as zeroed.
But counting on that would be a mistake.
On Thu, Sep 10, 2015 at 01:22:33PM -0700, David wrote:
Buggy, sure.
Zero (less) filling, that is the question.
Realloc has had a difficult history, and I try to avoid it if at all possible.
David
> On Sep 10, 2015, at 1:21 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
>
> Am I the only one that remembers realloc() being buggy on some systems?
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm 
8:41 p.m.
below
On Thu, Sep 10, 2015 at 4:21 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
Am I the only one that remembers realloc() being buggy
on some systems?
Amen... it was rarely useful. I always found realloc to one of the
part I could never trust. I do remember what you got back from any of the
malloc calls could vary widely. Particularly pre-ANSI C and working on
non-UNIX systems.
Malloc in general was always a tarbaby because there were (are) so many
implementations "in the wild." I used to advise our application people to
create something that was application specific and then call the local
malloc under the covers, but the chances that a general malloc
implementation would be optimal for your code was low.
Clem
11 Sep
11 Sep
12:13 a.m.
On Thu, 10 Sep 2015, David wrote:
I’ve just had a discussion with my boss about this and
he claimed that
it did at one point and I said it hasn’t in all the unix versions I’ve
ever played with (v6, v7, sys III, V, BSD 2, 3, 4, SunOS and Solaris).
Only V6? I did V5... Tell that to the young kids of today, and they
won't believe you.
My question to this illustrious group is: Did any Unix
or Unix like OS
ever zero fill on realloc?
Never in my lifetime, which meant that you got inspect someone's private
messages and there's someone knocking at my door and
#$%^&*\{{{
NO CARRIER
6:30 a.m.
On Thu, Sep 10, 2015 at 4:21 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
> Am I the only one that remembers realloc() being buggy on some systems?
Clem Cole <clemc(a)ccc.com> wrote:
Amen... it was rarely useful. I always found
realloc to one of the
part I could never trust. I do remember what you got back from any of the
malloc calls could vary widely. Particularly pre-ANSI C and working on
non-UNIX systems.
I would not say this applies today. The GLIBC realloc is very effective.
The place where I see this is in gawk, which special cases
a = a b # concatenate string b onto the end of string a
By using realloc to grow the contents of a and copying b's contents
onto the end I see a huge speedup over the dance of
char *p malloc(length(a) + length(b))
copy in a
copy in b
free old a
make a point at new storage
Arnold
3162
days inactive
3163
days old
9 comments
6 participants
participants (6)
-
arnold＠skeeve.com -
Clem Cole -
Dave Horsfall -
David -
Jim Capp -
Larry McVoy