[TUHS] Did realloc ever zero the new memory?

[TUHS] Did realloc ever zero the new memory?

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

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] Did realloc ever zero the new memory?

[Jim Capp]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

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@kdbarto.org> 
To: tuhs at 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 at minnie.tuhs.org 
https://minnie.tuhs.org/mailman/listinfo/tuhs 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150910/f4857c45/attachment.html>

[TUHS] Did realloc ever zero the new memory?

[Larry McVoy]

Am I the only one that remembers realloc() being buggy on some systems?

[TUHS] Did realloc ever zero the new memory?

[David]

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 at mcvoy.com> wrote:
> 
> Am I the only one that remembers realloc() being buggy on some systems?

[TUHS] Did realloc ever zero the new memory?

[Larry McVoy]

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 at 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 

[TUHS] Did realloc ever zero the new memory?

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

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 at 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 at 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 

[TUHS] Did realloc ever zero the new memory?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

below

On Thu, Sep 10, 2015 at 4:21 PM, Larry McVoy <lm at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150910/25a3e14c/attachment.html>

[TUHS] Did realloc ever zero the new memory?

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

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

[TUHS] Did realloc ever zero the new memory?

[arnold]

> On Thu, Sep 10, 2015 at 4:21 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> > Am I the only one that remembers realloc() being buggy on some systems?

Clem Cole <clemc at 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

[TUHS] Did realloc ever zero the new memory?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Fri, Sep 11, 2015 at 2:30 AM, <arnold at skeeve.com> wrote:

> I would not say this applies today. The GLIBC realloc is very effective.


​Fair enough​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150911/e849f4e1/attachment.html>

[TUHS] Did realloc ever zero the new memory?

[Jonathan Gevaryahu]

On 9/13/2015 11:20 PM, Greg 'groggy' Lehey wrote:
> On Sunday, 13 September 2015 at 16:09:55 +1000, Dave Horsfall wrote:
>> On Sat, 12 Sep 2015, Larry McVoy wrote:
>>
>>> That's a really good point.  Anyone like these?
>>>
>>> void *alloc(size_t bytes);
>>> void *realloc(void *old, size_t want);
>>>
>>> void *zalloc(size_t bytes);
>>> void *zealloc(void *old, size_t want);
>>>
>>> So alloc is new, we can have that.  Realloc() is OK?  Or not?  Does the
>>> current one have weird semantics?
>>>
>>> zalloc/zealloc are new, we can have those.
>>>
>>> If you guys like these I can push on Linus and the glibc people.
>> I'll vote for those, although my dev days are pretty much over.  I've
>> never liked malloc() etc not clearing memory, although it has been, ahem,
>> useful, in the past...
> http://xkcd.com/927/
>
> Greg
Why not crealloc? pronounced 'cereal-oc'? it would behave the same as 
realloc, but explicitly zeroes the area upon allocating it (and maybe 
also upon reducing the size of the area, it zeroes the area freed, or 
zeroes the area the memory structure was previously located at, if the 
whole memory structure has to be moved.)

Borrowing from 
http://pubs.opengroup.org/onlinepubs/009695399/functions/realloc.html :

The /crealloc/() function shall change the size of the memory object 
pointed to by /ptr/ to the size specified by /size/. The contents of the 
object shall remain unchanged up to the lesser of the new and old sizes. 
If the new size of the memory object would require movement of the 
object, the space for the previous instantiation of the object is 
zeroed, then freed. If the new size is larger, the contents of the newly 
allocated portion of the object are explicitly set to the value of 0. If 
/size/ is 0 and /ptr/ is not a null pointer, the object pointed to is 
zeroed, then freed. If the space cannot be allocated, the object shall 
remain unchanged.

If /ptr/ is a null pointer, /crealloc/() shall be equivalent to 
/calloc/() 
<http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html> 
for the specified size.

If /ptr/ does not match a pointer returned earlier by /calloc/() 
<http://pubs.opengroup.org/onlinepubs/009695399/functions/calloc.html>, 
/malloc/() 
<http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html>, 
/realloc/() or /crealloc/() or if the space has previously been 
deallocated by a call to /free/() 
<http://pubs.opengroup.org/onlinepubs/009695399/functions/free.html>, 
/realloc/() or /crealloc/(), the behavior is undefined.

The order and contiguity of storage allocated by successive calls to 
/crealloc/() is unspecified. The pointer returned if the allocation 
succeeds shall be suitably aligned so that it may be assigned to a 
pointer to any type of object and then used to access such an object in 
the space allocated (until the space is explicitly freed or 
reallocated). Each such allocation shall yield a pointer to an object 
disjoint from any other object. The pointer returned shall point to the 
start (lowest byte address) of the allocated space. If the space cannot 
be allocated, a null pointer shall be returned.


-- 
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com
jgevaryahu at hotmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150917/3ae728f5/attachment.html>

[TUHS] Did realloc ever zero the new memory?

[Greg 'groggy' Lehey]

On Sunday, 13 September 2015 at 16:09:55 +1000, Dave Horsfall wrote:
> On Sat, 12 Sep 2015, Larry McVoy wrote:
>
>> That's a really good point.  Anyone like these?
>>
>> void *alloc(size_t bytes);
>> void *realloc(void *old, size_t want);
>>
>> void *zalloc(size_t bytes);
>> void *zealloc(void *old, size_t want);
>>
>> So alloc is new, we can have that.  Realloc() is OK?  Or not?  Does the
>> current one have weird semantics?
>>
>> zalloc/zealloc are new, we can have those.
>>
>> If you guys like these I can push on Linus and the glibc people.
>
> I'll vote for those, although my dev days are pretty much over.  I've
> never liked malloc() etc not clearing memory, although it has been, ahem,
> useful, in the past...

http://xkcd.com/927/

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150914/57cb0dda/attachment.sig>

[TUHS] Did realloc ever zero the new memory?

[John Cowan]

Derek Fawcus scripsit:

> While I'd pronounce zealloc as Zee-alloc;  I'd not be inclined
> to pronounce zalloc that way,  nor as Zed-alloc, but as Zal-loc
> (rhymes with Sal-loc).  Maybe Larry had this pronounciation
> in mind?
> 
> Similarly,  I pronounce 'calloc' as Kal-loc not, See-alloc.

+1

> So other folk from England should have no trouble :-)

Nor other Yanks.  :-)

That, of course, leads directly to the vexed question of how to pronounce
"char".  For me, it is "tcharr", for others "care".

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"

[TUHS] Did realloc ever zero the new memory?

[Derek Fawcus]

On Sun, Sep 13, 2015 at 09:06:48AM +0200, markus schnalke wrote:
> Please note, that identifiers are usually remembered by sound
> not by letter sequence. `zalloc' and `zealloc' are likely to
> be pronounced similar

While I'd pronounce zealloc as Zee-alloc;  I'd not be inclined
to pronounce zalloc that way,  nor as Zed-alloc, but as Zal-loc
(rhymes with Sal-loc).  Maybe Larry had this pronounciation
in mind?

Similarly,  I pronounce 'calloc' as Kal-loc not, See-alloc.

So other folk from England should have no trouble :-)

DF

[TUHS] Did realloc ever zero the new memory?

[markus schnalke]

[2015-09-13 20:32] Dave Horsfall <dave at horsfall.org>
> On Sun, 13 Sep 2015, markus schnalke wrote:
> 
> > > void *alloc(size_t bytes);
> > > void *realloc(void *old, size_t want);
> > > 
> > > void *zalloc(size_t bytes);
> > > void *zealloc(void *old, size_t want);
> > 
> > Please note, that identifiers are usually remembered by sound not by 
> > letter sequence. `zalloc' and `zealloc' are likely to be pronounced 
> > similar and thus there is a good chance that this leads to confusion and 
> > errors. Furthermore, `calloc' and `zalloc' are prone to be pronounced 
> > equally or understood equally, especially by non-native speakers.
> 
> That, of course, depends upon how you pronounce "z".  In this part of the 
> world, it's "zed".  No confusion with "see" here down-under...

So, if these function will never be available to American English
speaking folks, then I'm all fine with the names. ;-)


meillo

[TUHS] Did realloc ever zero the new memory?

[Dave Horsfall]

On Sun, 13 Sep 2015, markus schnalke wrote:

> > void *alloc(size_t bytes);
> > void *realloc(void *old, size_t want);
> > 
> > void *zalloc(size_t bytes);
> > void *zealloc(void *old, size_t want);
> 
> Please note, that identifiers are usually remembered by sound not by 
> letter sequence. `zalloc' and `zealloc' are likely to be pronounced 
> similar and thus there is a good chance that this leads to confusion and 
> errors. Furthermore, `calloc' and `zalloc' are prone to be pronounced 
> equally or understood equally, especially by non-native speakers.

That, of course, depends upon how you pronounce "z".  In this part of the 
world, it's "zed".  No confusion with "see" here down-under...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
 I'll support shark-culling when they have been observed walking on dry land.

[TUHS] Did realloc ever zero the new memory?

[markus schnalke]

[2015-09-12 18:15] Larry McVoy <lm at mcvoy.com>
> 
> That's a really good point.  Anyone like these?
> 
> void *alloc(size_t bytes);
> void *realloc(void *old, size_t want);
> 
> void *zalloc(size_t bytes);
> void *zealloc(void *old, size_t want);

Please note, that identifiers are usually remembered by sound
not by letter sequence. `zalloc' and `zealloc' are likely to
be pronounced similar and thus there is a good chance that
this leads to confusion and errors. Furthermore, `calloc' and
`zalloc' are prone to be pronounced equally or understood
equally, especially by non-native speakers.

Choosing good identifiers is a tough task.


meillo

[TUHS] Did realloc ever zero the new memory?

[Dave Horsfall]

On Sat, 12 Sep 2015, Larry McVoy wrote:

> That's a really good point.  Anyone like these?
> 
> void *alloc(size_t bytes);
> void *realloc(void *old, size_t want);
> 
> void *zalloc(size_t bytes);
> void *zealloc(void *old, size_t want);
> 
> So alloc is new, we can have that.  Realloc() is OK?  Or not?  Does the
> current one have weird semantics?
> 
> zalloc/zealloc are new, we can have those.
> 
> If you guys like these I can push on Linus and the glibc people.

I'll vote for those, although my dev days are pretty much over.  I've 
never liked malloc() etc not clearing memory, although it has been, ahem, 
useful, in the past...

And I vaguely recall alloc() from Ed5 days (it was an improvement upon 
"sys brk", after all), so it's not new.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
 I'll support shark-culling when they have been observed walking on dry land.

[TUHS] Did realloc ever zero the new memory?

[Charles Anthony]

On Sat, Sep 12, 2015 at 6:30 PM, Random832 <random832 at fastmail.com> wrote:

> Doug McIlroy <doug at cs.dartmouth.edu> writes:
> > It's odd that the later introduction of calloc() as a zeroing malloc()
> > has never been complemented by a similar variant of realloc().
>
> Speaking of calloc, was it ever envisioned that any implementation would
> do anything more sophisticated with the two arguments than multiply them
> together (and detect overflow)? Has any such implementation ever
> existed? It seems like one of the great mysteries of the C library
> design, especially since early implementations didn't do overflow
> checking.
>
>
Alignment perhaps?

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150912/3942e5af/attachment.html>

[TUHS] Did realloc ever zero the new memory?

[Random832]

Doug McIlroy <doug at cs.dartmouth.edu> writes:
> It's odd that the later introduction of calloc() as a zeroing malloc()
> has never been complemented by a similar variant of realloc().

Speaking of calloc, was it ever envisioned that any implementation would
do anything more sophisticated with the two arguments than multiply them
together (and detect overflow)? Has any such implementation ever
existed? It seems like one of the great mysteries of the C library
design, especially since early implementations didn't do overflow
checking.

The existence of cfree also suggests an intention to eventually have it
use a separate arena from malloc.

[TUHS] Did realloc ever zero the new memory?

[Larry McVoy]

On Sat, Sep 12, 2015 at 08:32:57PM -0400, Doug McIlroy wrote:
> It's odd that the later introduction of calloc() as a zeroing malloc()
> has never been complemented by a similar variant of realloc().

That's a really good point.  Anyone like these?

void *alloc(size_t bytes);
void *realloc(void *old, size_t want);

void *zalloc(size_t bytes);
void *zealloc(void *old, size_t want);

So alloc is new, we can have that.  Realloc() is OK?  Or not?  Does the
current one have weird semantics?

zalloc/zealloc are new, we can have those.

If you guys like these I can push on Linus and the glibc people.

[TUHS] Did realloc ever zero the new memory?

[Doug McIlroy]

> Did any Unix or Unix like OS ever zero fill on realloc?

> On zero fill, I doubt many did that.  Many really early on when memory
> was small.

This sparks rminiscence. When I wrote an allocation strategy somewhat
more sophisticated than the original alloc(), I introduced realloc() and
changed the error return from -1 to the honest pointer value 0. The
latter change compelled a new name; "malloc" has been with us ever since.

To keep the per-byte cost of allocation low, malloc stuck with alloc's
nonzeroing policy. The minimal extra code to handle calls that triggered
sbrk had the startling property that five passes through the arena might
be required in some cases--not exactly scalable to giant virtual address
spaces!

It's odd that the later introduction of calloc() as a zeroing malloc()
has never been complemented by a similar variant of realloc().

> Am I the only one that remembers realloc() being buggy on some systems?

I've never met a particular realloc() bug, but realloc does inherit the
portability bug that Posix baked into malloc(). Rob Pike and I
requested that malloc(0) be required to return a pointer distinct from
any live pointer. Posix instead allowed an undefined choice between
that behavior and an error return, confounding it with the out-of-memory
indication. Maybe it's time to right the wrong and retire "malloc".
The name "alloc" might be recycled for it. It could also clear memory
and obsolete calloc().

Doug

[TUHS] Did realloc ever zero the new memory?

[Greg 'groggy' Lehey]

On Saturday, 12 September 2015 at 15:16:51 +1000, Dave Horsfall wrote:
> On Thu, 10 Sep 2015, Norman Wilson wrote:
>
>>   #$%^&*\{{{
>>
>>   NO CARRIER
>>
>> +++
>> ATH
>
> My favourite would be:
>
> +++
> (pause - this was necessary)
> ATZ
>
> I.e. a reset.
>
> I think there were even worse ones in the Hayes codes, like ATH3 or
> something.  Dammit, but mental bit-rot is setting in.

Of course, you haven't forgotten:

  UNIX is a registered trade mark of AT&T
  AT&T is a modem test command.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150912/6b999604/attachment.sig>

[TUHS] Did realloc ever zero the new memory?

[Dave Horsfall]

On Thu, 10 Sep 2015, Norman Wilson wrote:

>   #$%^&*\{{{
> 
>   NO CARRIER
> 
> +++
> ATH

My favourite would be:

+++
(pause - this was necessary)
ATZ

I.e. a reset.

I think there were even worse ones in the Hayes codes, like ATH3 or 
something.  Dammit, but mental bit-rot is setting in.

Of course, I never did such an evil thing, your honour...  Honest!  Never!

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
 I'll support shark-culling when they have been observed walking on dry land.

[TUHS] Did realloc ever zero the new memory?

[scj]

Maybe I can clear up some of the confusion.  I too believe that malloc and
realloc never zeroed the newly added memory.  However, at some point
someone realized that when Unix added a page to the memory available to a
process, it didn't clear that page.  Somebody wrote a small program that
would, from time to time, malloc a chunk of memory and look for
interesting things in it (e.g., ASCII strings).  It was rather effective,
and soon Unix was changed so that any new pages were cleared before they
were added to the process.

Many mallocs tried to allocate a page if you asked for that size memory
(it depended on whether the control info was in the same arena as the
memory blocks or not).  So if your program used such a malloc and you
allocated full pages at a time, you might have silently seen malloc turn
into calloc, albeit in a completely non-portable way.  I suspect realloc
worked similarly.

Steve


> I've never heard before of a belief that the new memory belonging
> to realloc is always cleared, except in conjunction with the utterly-
> mistaken belief that that's true of malloc as well.  I don't think it
> was ever promised to be true, though it was probably true by accident
> just often enough (just as often as with malloc) to fool the careless.
>
> Norman Wilson
> Toronto ON
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

[TUHS] Did realloc ever zero the new memory?

[Norman Wilson]

I've used realloc a lot, and never run into bugs.  Maybe I've just
been lucky, or maybe it's that I probably didn't use it that much
until the latter 1980s, and then more with pukka Doug malloc code
than with the stuff floating around elsewhere.

Never mind that sometime around 1995 I found a subtle bug in the
pukka Doug malloc (not realloc): arena blew up badly when presented
with a certain pattern of alternating small and large allocs and frees,
produced by a pukka Brian awk regression test.  I had a lot of (genuine)
fun tracking that down, writing some low-level tools to extract the
malloc and free calls and sizes and then a simulator in (what else?)
awk to test different fixes.  Oh, for the days when UNIX was that
simple.

I've never heard before of a belief that the new memory belonging
to realloc is always cleared, except in conjunction with the utterly-
mistaken belief that that's true of malloc as well.  I don't think it
was ever promised to be true, though it was probably true by accident
just often enough (just as often as with malloc) to fool the careless.

Norman Wilson
Toronto ON