I have painful memories from programming 101 in the twilight of the punch card era that initializing variables was a big deal in FORTRAN and COBOL. After declaring a long list of variables for a convoluted assignment one would have to go back and set equal to zero in FORTRAN and "MOVE SPACES TO" in COBOL. There was no "cut and paste" this was the punch card era (we also had to walk seven miles uphill barefoot in the snow to school -- joke). Assuming one did not get a cryptic compiler message (and in those days all compiler messages were cryptic, "Probable user error:") one would get a bizarre run time error at a time when one did not clearly understand the difference between "compile time" and "run time" (the batch job was initialized with cryptic JCL cards and returned one long printout on green bar paper so it took careful reading to understand what the computer was doing). The UNIX shells (or even the MS-DOS command line) were such an improvement over IBM mainframe JCL hell.
In a shared mainframe or minicomputer environment there was constant clutter in memory. This was long before Internet era security concerns. Wikipedia has an article on "Uninitialized Variable" with a C example and references a C standard: "ISO/IEC 9899:TC3 (Current C standard)" <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf> (PDF). 2007-09-07. p. 126. Retrieved 2008-09-26. Section 6.7.8, paragraph 10. If uninitialized variables are allowed and memory is not automatically set to zero the program will have non-deterministic run-time behavior because of the random clutter in memory. Jim Callahan <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-2115-v2-a> This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-2115-v2-a> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, Mar 23, 2016 at 1:23 PM, Doug Nebeker <admin at poweradmin.com> wrote: > > For obvious security reasons all allocations from the Operating System > are pre-initialized to 0x00. > > Time to bash Windows, but according to the docs for HeapAlloc, memory is > not automatically initialized to 0 > > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa366597(v=vs.85).aspx > > This fits with my experience as well. > > Doug > > > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto: > sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Keith Medcalf > Sent: Tuesday, March 22, 2016 8:41 PM > To: SQLite mailing list > Subject: Re: [sqlite] Article about pointer abuse in SQLite > > > > This discussion on the nature of undefined behaviour code is > > interesting. I don't know the reasoning, but it seems that VS6 often > > initialized things to 0xcd in debug mode and (usually) had memory > > uninitialized to 0x00 when complied in Release (perhaps 0x00 just > > happens to be what was on the stack or heap). I presume this wasn't > > just to make people suffer when things don't work the same in debug > > vs release mode. > > The initialization of memory to non-0x00 is a compiler function. > > For obvious security reasons all allocations from the Operating System are > pre-initialized to 0x00. This is so that your program cannot request a big > hunk of virtual memory which is full of a predecessor process data and then > proceed to search it for nifty things like previously used private keys, > userids, passwords, and so forth. Such behaviour is required for any > Operating Systems to obtain any security certification level whatsoever. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
