Jeff Rife posted:

> Unless the process was swapped out between reading the first "c" and
> reading the second "c", as was mentioned before.  Since the memory is
> unitialized, the hardware doesn't have to restore it to the same state
> if it keeps track of "(un)initialized memory".

I don't understand.

Let's assume that CHAR_BIT =3D=3D 8. We define an "unsigned char" variabl=
e as=20
follows:

    unsigned char c;

This variable must contain a value. I'm not saying that in a "C++=20
Standard" kind of way, but rather in a "Laws of Physics" kind of way.=20
Computers have memory which consists of bits, and these bits must be=20
either 1 or 0. No language Standard overrides this (or mathematics for=20
that matter).

All eight bits are "value representation" bits, and it's unsigned, so=20
there's no invalid bit patterns.

So, looking at it from a human perspective, we can say that "c" contains=20
a random value (please bear with me). So if we take this random value and=
=20
subtract it from itself, we're left with zero:

    return c - c;

So here's where I fail to understand why this could yield anything other=20
than zero.


-Tom=E1s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tom   s" wrote:

> This variable must contain a value. I'm not saying that in a "C++
> Standard" kind of way, but rather in a "Laws of Physics" kind of way.
> Computers have memory which consists of bits, and these bits must be
> either 1 or 0.

The idea seems to be that the compiler could assign the variable c to a
register rather than placing it at a location in memory.  Now, once a
register variable has a determinate value, there's no question that the
compiler is required to "protect" that value...i.e. it's not free
simply use that register for some other purpose.  The question that
came up in the committee was is the compiler required to "protect" the
value of an uninitialized register variable as well?  If not, then two
reads of the uninitialized variable could return different results, if
some instruction between the two reads altered the content of the
register in question.

The consensus seems to have been that the compiler is *not* required to
ensure that successive reads of an uninitialized variable return the
same result, and therefore that such a register could be used for any
purpose until the point at which the register variable is assigned a
determinate value.

In the current example, of course, this is extremely unlikely to arise
in practice...the compiler would have to be actively malicious, since
there's really nothing to do in the program that could overwrite the
uninitialized variable.  But it seems to be the case that the standard
doesn't guarantee a zero result.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Tom   s" wrote:
..
> So, looking at it from a human perspective, we can say that "c" contains
> a random value (please bear with me). So if we take this random value and
> subtract it from itself, we're left with zero:

Yes, that's true. However, your key mistake is assuming that the random
value will be subtracted from itself. In "c-c', there are nominally two
seperate reads of the value of 'c'. The decision of the co mmittee was
that, when 'c' has not yet been initialized, the implementor has no
obligation to make sure that same random value is retrieved by each
read. It could read one piece of memory to extract one of the values,
and an entirely different piece of memory for the second one. It could
read the same piece of memory each time, but allow the bit pattern
contained in that piece of memory to change between those two reads.

For this particularly simple case, it's rather unlikely. Any
sufficiently good compiler is likely to optimize "c-c" to 0, and never
even attempt to actually read it. However, if the two accesses to the
same uninitialized variable are seperated  by one or more expressions,
it becomes more plausible that the piece of memory used for the first
read might represent a different value than the piece of memory used
for the second read.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1147903069.877175.148820@j73g2000cwa.googlegroups.com>,
johnchx2@yahoo.com writes
>The consensus seems to have been that the compiler is *not* required to
>ensure that successive reads of an uninitialized variable return the
>same result, and therefore that such a register could be used for any
>purpose until the point at which the register variable is assigned a
>determinate value.

Yes, but it isn't just registers. We have the whole issue of paging
memory and because paging RAM to disc is a very slow process (relatively
speaking) we do not want to require that uninitialised memory be
preserved through a cycle of paging. And indeterminate value is exactly
that, one that cannot be reliably determined by any process, all that is
required is that it be one of a set of possible values (i.e.
bit-patterns) and it can arbitrarily change from moment to moment. The
example of paging is simply to demonstrate that allowing such arbitrary
change is actually useful.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

johnchx2@yahoo.com wrote:
> the compiler would have to be actively malicious

Not really. All it takes is for the compiler to
recognize that an expression involves the use of
an uninitialized value. It can then go ahead and
substitute an arbitrary convenient value for the
entire expression, perhaps zero. If there are
several such expressions, all set to zero, then
it would appear from the source code that the
uninitialized variable was taking on a different
value in each.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]