Re: no movement on Critical issues; 2.16 in Oct ?

[Graham Percival]

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