Tom=E1s (NULL@NULL.NULL) wrote in comp.std.c++:
> >int main(void)
> >{
> >    unsigned char c;
> >    return c-c;
> >}
>=20
>=20
> Given that an unsigned char has no invalid bit patterns, there shouldn'=
t=20
> be any time, place, system, implementation or platform where this code=20
> would return anything other than zero.

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 know for a fact that many x86 compliers will put this variable into
just such an "uninitialized memory" area, which allows the code on disk
to be smaller, since the value doesn't have to be stored, just a number
that indicates the total size of the unitialized data.

This--like many examples of this sort of behavior--also assumes that
the compiler doesn't optimize it away completely.

--=20
Jeff Rife | "...who paved the way for The Alan Parsons'=20
          |  Project...which I believe was some sort=20
          |  of a hovercraft."=20
          |         -- Homer Simpson=20

---
[ 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:
> >int main(void)
> >{
> >    unsigned char c;
> >    return c-c;
> >}
>
>
> Given that an unsigned char has no invalid bit patterns, there shouldn't
> be any time, place, system, implementation or platform where this code
> would return anything other than zero.

As Francis Glassborow pointed out, in Sydney a response was given to a
DR which said that not only is the value of 'c' indeterminate, it can
be a different indeterminate value each time it is read. The
implication is that the implementation doesn't have to really reserve
any space for an object until after the first time it's actually
written to. It can use a different temporary piece of memory for each
read. Even if it uses the same memory for both reads, it's allowed to
use that memory for some other purpose between those two reads,
possibly changing its value.

If that's the case, then a non-zero value for c-c is perfectly
feasible; I think it's unlikely but it's certainly possible.

Since he was responding to a message I wrote that talked about both C99
and C++, I'm not sure which committe's meeting he was referring to.
However, the simple fact that either of the two committees issued such
a ruling demonstrates that a value of 0 for c-c should not be
considered a foregone conclusion.


---
[ 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 <1147873090.546428.318480@j55g2000cwa.googlegroups.com>,
kuyper@wizard.net writes
>Since he was responding to a message I wrote that talked about both C99
>and C++, I'm not sure which committe's meeting he was referring to.
>However, the simple fact that either of the two committees issued such
>a ruling demonstrates that a value of 0 for c-c should not be
>considered a foregone conclusion.

Yes, I should have made it clear. The actual decision was made by WG14
but both it and the rational for it would make sense in either language.


--
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                      ]

>int main(void)
>{
>    unsigned char c;
>    return c-c;
>}


Given that an unsigned char has no invalid bit patterns, there shouldn't
be any time, place, system, implementation or platform where this code
would return anything other than zero.

-Tom   s

---
[ 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                      ]