Xref: news2.mv.net comp.os.msdos.djgpp:5582
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Zeroing of new() memory
Date: Tue, 02 Jul 1996 08:22:42 CDT
Organization: Rice University, Houston, Texas
Lines: 21
Message-ID: <31d922a2.sandmann@clio.rice.edu>
References: <6C0AM0qxr5B AT jocokko DOT edition DOT bonbit DOT org>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> Yes, I see the point, thanks for the flag, I'll use it. Has this behaviour  
> changed because of the new ANSI standard ?

The behavior changed because when I wrote the V2 memory management, I wanted
it to be faster than V1.x ... purely a performance issue.  Code which assumes
memory is zeroed is buggy and not very portable, so it's reasonable to 
expect this code to be fixed.  But there is a bunch of it out there, and 
not as many programming hours as we would like, so the crt0 flag allows you
to have a "compatible" but slow behavior.  The V1.x malloc() code and 
the edebug/fsdb debugger symbol code both expected memory zeroing, so 
bad coding practices hit the developers too :-)

The speed difference isn't very noticeable on small memory programs, but
if you are working with virtual memory, the extra modification of each
page can double the number of page faults in initialization and force 
smart memory managers to commit a page when one really isn't needed
(for the stack and the power of 2 malloc'ing extra, for example).

So for maximum compatibility (with V1.x and unix) you want to zero memory 
and use the unixy sbrk() algorithm - but these might not be the best things
for the optimal port.