> 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-boun...@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
