The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (scj@yaccman.com)
Subject: [TUHS] Did realloc ever zero the new memory?
Date: Fri, 11 Sep 2015 09:44:56 -0700	[thread overview]
Message-ID: <72b8190786e0faf1ecb7bd11c94cff87.squirrel@webmail.yaccman.com> (raw)
In-Reply-To: <1441986088.9291.for-standards-violators@oclsc.org>

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
>





  reply	other threads:[~2015-09-11 16:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 15:41 Norman Wilson
2015-09-11 16:44 ` scj [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-09-13  0:32 Doug McIlroy
2015-09-13  1:15 ` Larry McVoy
2015-09-13  6:09   ` Dave Horsfall
2015-09-14  3:20     ` Greg 'groggy' Lehey
2015-09-17  4:42       ` Jonathan Gevaryahu
2015-09-13  7:06   ` markus schnalke
2015-09-13 10:32     ` Dave Horsfall
2015-09-13 11:06       ` markus schnalke
2015-09-13 12:13     ` Derek Fawcus
2015-09-13 13:45       ` John Cowan
2015-09-13  1:30 ` Random832
2015-09-13  2:29   ` Charles Anthony
     [not found] <1441931343.25526.for-standards-violators@oclsc.org>
2015-09-12  5:16 ` Dave Horsfall
2015-09-12  6:47   ` Greg 'groggy' Lehey
2015-09-10 19:52 David
2015-09-10 20:10 ` Jim Capp
2015-09-10 20:21   ` Larry McVoy
2015-09-10 20:22     ` David
2015-09-10 20:27       ` Larry McVoy
2015-09-10 20:29         ` David
2015-09-10 20:41     ` Clem Cole
2015-09-11  6:30       ` arnold
2015-09-11 14:36         ` Clem Cole
2015-09-11  0:13 ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=72b8190786e0faf1ecb7bd11c94cff87.squirrel@webmail.yaccman.com \
    --to=scj@yaccman.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).