On Sun, Jul 31, 2011 at 10:26:11AM +0200, David Kastrup wrote: > Modern operating systems don't give your code any leftovers from a > previous run. That would be a security violation.
I'm certain that I've seen an uninitialized variable being 123456789 in some cases, and 0 in others. I sincerly doubt that modern operating systems remember what collection of bits were in memory at just before the first initialization, so the security step would surely be simply writing 0s to that location in memory. I think it's quite reasonable that if C++ interpreted a random collection of bits (i.e. uninitailized memory), guile would barf when trying to do some math with the resulting value. But since that pile of bits would be set to 0 on program exit, and if the initial programmer just assumed that uninitialized variables were 0 (as they are in java), that would very neatly explain why we've never seen two successive runs of this problem. > And even user stack initialization below the stack pointer is not > stochastical. Hmm, I may be misunderstanding this sentence due to my relative ignorance of low-level OS stuff (I had a quite varied career as an undergraduate). If you mean "the computer starts reserving pieces of memory for variables in different places in memory on each run", then my 0-theorizing above is false. But I'm pretty certain that I've seen student programs (running in 3-year-old cygwin on windows 2000, so perhaps not the most secure of environments) share unitialized variable locations across program runs. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
