In article <3pqbef$t0m@kai.com>, robison@kai.com (Arch Robison) wrote:
>The proposed standard does not say much about the use of uninitialized
>objects with automatic storage duration.  There are some surprising semantics
>that are perhaps allowed by the standard. For example, consider the following
>program.
>
> #include <iostream.h>
> main() {
>     int x;  // No initializer for x
>     if( x==0 )
>  cout << "zero ";
>     if( x!=0 )
>  cout << "non-zero\n";
> }
>[...]
>
> An uninitialized memory location randomly fluctuates until
> it is initialized or assigned a value.


Is that architecture meant to have some fluctuator inside? How does that
architecture tell the difference between 'uninitialized' and 'trashed' or
'deinitialized' memory? Does that architecture also fluctuate registers of the
main CPU during the program execution, if they are not initialized
periodically? Does it have CPU at all?


>[...]
>My own personal view is that the "fluctuating memory" model should be
>allowed by the standard, since it gives optimizers more freedom, and
>writing programs that depend upon the non-fluctuating model is a
>questionable practice.  My questions for interested parties are:
>
> 1) Does the proposed standard prohibit the semantics above
>    for uninitialized objects with automatic storage duration?
>
> 2) Should the standard clarify whether the semantics above
>    are allowed for a conforming implementation?

Please let me follow-up asking another questions:

Isn't it true that memory for the object is allocated at the moment of
definition, and becomes 'private' part of the object (and therefore cannot be
changed without a reason)? How the proposed standard treats the passing of
uninitialized object to a function by reference?

Sorry for my stupid comments, but taking the similar technique "what if" the
object in the program will not be of type int, but of user-defined type with
some default constructor. Should the constructor call be delayed until some
hypothetical time, when the object is _really_ used? How do we (or does the
draft) define "_real_ use"?

Thank you for not slapping me immediately.

Victor.

-------< Internet: vbazarov@imsisoft.com, CompuServe: 74633,2430 >

In article <3pr06o$o28@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM writes:
>In article t0m@kai.com, robison@kai.com (Arch Robison) writes:
>>The proposed standard does not say much about the use of uninitialized
>>objects with automatic storage duration.  There are some surprising semantics
>>that are perhaps allowed by the standard.
>
>That's true, because NO semantics are assigned by the standard. According
>to 8.5, "Initializers", an uninitialized auto variable has indeterminate
>value, meaning you cannot assume anything at all about its value.
>
>You cannot even assume you can read the "value" without causing a
>hardware trap. Indeed, such a trap occurs on some machines.

The phrase "indeterminate value" is never defined in the C++ draft
standard, and is somewhat ambiguous.  It could mean "a value that's valid
for the object, but no particular value is required by the standard"
(i.e. an unspecified value).

The C standard specifies that accessing a variable with indeterminate value
results in undefined behavior, but the C++ draft contains no such language
(I just searched for "unspecified" and "indeterminate" in all the likely
chapters).  The C++ draft says that some provisions of the C standard apply
to C++ by reference, but I don't think it says that we can assume other
aspects of C are inherited merely because the C++ standard is silent on
those issues.

Of course, there's the old fallback: if it's not explicitly defined, it
should be presumed to be undefined.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@bbnplanet.com

In article <3pt2mi$avk_006@news.dnai.com> vbazarov@imsisoft.com (Victor Bazarov) writes:

   Path: jussieu.fr!univ-lyon1.fr!swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!gatech!news.mathworks.com!uhog.mit.edu!sgiblab!cygnus.com!news.zeitgeist.net!hilbert.dnai.com!vbazarov
   From: vbazarov@imsisoft.com (Victor Bazarov)
   Newsgroups: comp.std.c++
   Date: Tue, 23 May 95 16:32:18 GMT
   Organization: IMSI
   Lines: 57
   References: <3pqbef$t0m@kai.com>
   NNTP-Posting-Host: vbazarov.imsisoft.com
   X-Newsreader: News Xpress Version 1.0 Beta #3

|   In article <3pqbef$t0m@kai.com>, robison@kai.com (Arch Robison) wrote:
|   >The proposed standard does not say much about the use of uninitialized
|   >objects with automatic storage duration.  There are some surprising semantics
|   >that are perhaps allowed by the standard. For example, consider the following
|   >program.
|   >
|   > #include <iostream.h>
|   > main() {
|   >     int x;  // No initializer for x
|   >     if( x==0 )
|   >  cout << "zero ";
|   >     if( x!=0 )
|   >  cout << "non-zero\n";
|   > }
|   >[...]
|   >
|   > An uninitialized memory location randomly fluctuates until
|   > it is initialized or assigned a value.


=   Is that architecture meant to have some fluctuator inside? How does that
=   architecture tell the difference between 'uninitialized' and 'trashed' or
=   'deinitialized' memory? Does that architecture also fluctuate registers of the
=   main CPU during the program execution, if they are not initialized
=   periodically? Does it have CPU at all?

|   >[...]
|   >My own personal view is that the "fluctuating memory" model should be
|   >allowed by the standard, since it gives optimizers more freedom, and
|   >writing programs that depend upon the non-fluctuating model is a
|   >questionable practice.


I presently work on a on a virtual machine model that can be considered
as randomly fluctuating in such a case as above. This machine model is
used to perform smart low level code optimisations, and in particular
code scheduling for superscalar processors (change execution order
of instructions to improve parallelism).
Well, the idea is that I build a dependency graph between producers
and users of vars. In the case above, there is no producer at all,
so nothing oblige the code optimiser to use the same memory location
for the two occurences of x. In fact in my model there is not any
dependency between the two occurences of X and the above program
could even output "non-zero" "zero" after scheduling for all I know,
(I'm not speaking of the actual C++ standard there that disallow
such a behaviour, if I understand correctly the thread about
sequence points, Well, I didn't say I liked this restriction).

In article t0m@kai.com, robison@kai.com (Arch Robison) writes:
>The proposed standard does not say much about the use of uninitialized
>objects with automatic storage duration.  There are some surprising semantics
>that are perhaps allowed by the standard.

That's true, because NO semantics are assigned by the standard. According
to 8.5, "Initializers", an uninitialized auto variable has indeterminate
value, meaning you cannot assume anything at all about its value.

You cannot even assume you can read the "value" without causing a
hardware trap. Indeed, such a trap occurs on some machines.
---
Steve Clamage, stephen.clamage@eng.sun.com

The proposed standard does not say much about the use of uninitialized
objects with automatic storage duration.  There are some surprising semantics
that are perhaps allowed by the standard.  For example, consider the following
program.

 #include <iostream.h>
 main() {
     int x;  // No initializer for x
     if( x==0 )
  cout << "zero ";
     if( x!=0 )
  cout << "non-zero\n";
 }

Can the program above print "zero non-zero" when compiled by a C++ compiler
that conforms to the draft standard?  Before you respond with a definitive
"no!", please consider that the program might be running on a hypothetical
architecture with the following characteristic:

 An uninitialized memory location randomly fluctuates until
 it is initialized or assigned a value.

On such a machine, the example program might print "zero non-zero",
or nothing, or one of the two obvious results.

My own personal view is that the "fluctuating memory" model should be
allowed by the standard, since it gives optimizers more freedom, and
writing programs that depend upon the non-fluctuating model is a
questionable practice.  My questions for interested parties are:

 1) Does the proposed standard prohibit the semantics above
    for uninitialized objects with automatic storage duration?

 2) Should the standard clarify whether the semantics above
    are allowed for a conforming implementation?

Arch D. Robison    Kuck & Associates Inc.
robison@kai.com    1906 Fox Drive
217-356-2288       Champaign IL 61820