Date: Mon, 16 Sep 1996 21:18:02 -0400
From: dj (DJ Delorie)
Message-Id: <199609170118.VAA20545@delorie.com>
To: djgpp AT delorie DOT com
In-reply-to: <199609170101.LAA14759@gbrmpa.gov.au> (leathm@solwarra)
Subject: Re: Possible static data zeroisation bug in DJGPP v2?


> > One of its functions is precisely to do this chore.
> 
> Correct me if I'm wrong, but wasn't this changed so that it _did not_ zero
> the code for performance reasons?
>
> > Sorry, but the Standard says the converse.
> 
> Whatever. It doesn't really matter. (No flames...this is a comment.)

You two are talking about two completely different things.  Here's the
real scoop:

* If you have any static, but uninitialized variables, like these:

	int q;
	char foo[500];

  then the DJGPP startup will guarantee that they start off with
  binary zeros in them.  This is required by ANSI, and thus it is so.

* If you call malloc(), and the DJGPP runtime must increase the amount
  of system memory you are using, the newly allocated system memory is
  not zeroed.  Thus, you can never assume anything about what malloc (or
  sbrk) returns in its memory.  Note that since malloc() may reuse
  memory, you couldn't depend on it being zero before either.  Use
  calloc() to allocate zeroed memory.

> ie: id needed some more performance, so 

It wasn't id.  It was ARDI.