Is the following code legal?

[Alf P. Steinbach]

* Kai-Uwe Bux:

I did a search for "indeterminate" in my electronic version of the standard,
and I did not find a statement to that extend. I would be grateful for
chapter and verse.

§4.1/1 "... if the object is uninitialized, a program that necessitates
this conversion [to rvalue] has undefined behavior".

I don't think it ever was /meant/ to cover int values, but, it does.

 

[Alf P. Steinbach]

* AnalogFile:

Can you point me to where in the standard it says so?

AFAIK it is defined behavior (with indeterminate result) for every POD
type except when dereferencing a pointer.

Now I just replied to the same question posted by Kai-Uwe...

 

[AnalogFile]

* Kiuhnm:
Using an indeterminate value, for anything, is formally UB.

....
It appears that almost all uses (and most definitely all interesting uses)
of indeterminate values lead to undefined behavior per the catch all clause
in [1.3.12]: "Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition of
behavior." However, one could argue that in the case of

No. "omits the description of any explicit definition of behavior" does
not cover indeterminate values.

int x;

creates and x with indeterminate value. But it's defined behavior.

You can even use the x.

int x;
cout << x;

writes a value to standard output. Not guarantees on what value, except
it's in the range of ints. It's defined behavior.

If it was undefined a compiler could power off your machine with that
code. But it is defined and the only thing a conforming compiler can do
is write a value to standard output.

 

[AnalogFile]

Rolf Magnus ha scritto:

It doesn't say that. It just says that, when the right hand side is
evaluated, the name 'x' already exists. It doesn't say anything about the
behavior of initializing x with an indeterminate value.

3.3.1#1:
"[...]Here the second x is initialized with its own (indeterminate)
value."

And again, it doesn't say that initializing it with an indeterminate value
is legal, just that it is done here, because x is known before it is
initializied, so the name can be used for the initializer.

When the standard says: "this happens" it means that "this happens" is
the legal, defined, behavior. Undefined behavior is when the standard
says something is undefined or when it says nothing at all.

Also "indeterminate value" is a defined behavior for initialization in
many other cases.

 

[Kiuhnm]

Rolf Magnus ha scritto:

And again, it doesn't say that initializing it with an indeterminate value
is legal, just that it is done here, because x is known before it is
initializied, so the name can be used for the initializer.

I cannot believe a formal example contains illegal code (if not
specifically noted).
Anyway, where does the standard say that code is illegal?

Kiuhnm

 

[AnalogFile]

* Kai-Uwe Bux:

I did a search for "indeterminate" in my electronic version of the
standard,
and I did not find a statement to that extend. I would be grateful for
chapter and verse.

§4.1/1 "... if the object is uninitialized, a program that necessitates
this conversion [to rvalue] has undefined behavior".

I don't think it ever was /meant/ to cover int values, but, it does.

Does not apply. Quote the whole text!

"If the object to which the lvalue refers is not
an object of type T and is not an object of a type derived from T, or if
the object is uninitialized, a program
that necessitates this conversion has undefined behavior."

only if a conversion is required because the object is not already of
the required type, then the object must be initialized.

In

int x=x;

no conversion is required and that text does not apply.

 

[Alf P. Steinbach]

* AnalogFile:

* Kai-Uwe Bux:

Alf P. Steinbach wrote:

* Kiuhnm:
Then "int x = x;" is /not/ undefined (e.g. a standard-compliant
compiler
cannot format your hard disk).
Using an indeterminate value, for anything, is formally UB.

I did a search for "indeterminate" in my electronic version of the
standard,
and I did not find a statement to that extend. I would be grateful for
chapter and verse.

§4.1/1 "... if the object is uninitialized, a program that
necessitates this conversion [to rvalue] has undefined behavior".

I don't think it ever was /meant/ to cover int values, but, it does.

Does not apply. Quote the whole text!

"If the object to which the lvalue refers is not
an object of type T and is not an object of a type derived from T, or if
the object is uninitialized, a program
that necessitates this conversion has undefined behavior."

only if a conversion is required because the object is not already of
the required type, then the object must be initialized.

No, sorry, that's just wishfulness on your part.

This paragraph mainly applies to conversion T -> T, where you have an
lvalue of type T and end up with an rvalue of type T.

There is a bit more, type-wise, regarding classes, but for primitive
types like int "the type of the rvalue is the cv-unqualified version of
T", i.e., the conversion is then cv T -> T for any cv-qualification.

 

[Victor Bazarov]

Rolf Magnus ha scritto:
It doesn't say that. It just says that, when the right hand side is
evaluated, the name 'x' already exists. It doesn't say anything
about the behavior of initializing x with an indeterminate value.
3.3.1#1:
"[...]Here the second x is initialized with its own (indeterminate)
value."

And again, it doesn't say that initializing it with an indeterminate
value is legal, just that it is done here, because x is known before
it is initializied, so the name can be used for the initializer.

When the standard says: "this happens" it means that "this happens" is
the legal, defined, behavior.

None of what the Standard says in "Notes" or "Examples" is normative.

Undefined behavior is when the standard
says something is undefined or when it says nothing at all.

Also "indeterminate value" is a defined behavior for initialization in
many other cases.

Yes, but the fact that you need to _extract_ that value from an object
makes the behaviour undefined.

V

 

[AnalogFile]

Victor Bazarov wrote:
....

Yes, but the fact that you need to _extract_ that value from an object
makes the behaviour undefined.

If what you say was true, a conforming C++ compiler could translate the
following code:

#include <iostream>
int main()
{
int x;
std::cout << x;
}

to code that formats you disk.
I think it cannot.

And I see nowere in the standard any wording that says that extracting
an undetermined value from a POD is undefined. But I do find wordings
that say that extracting a value is defined and that initializing with
undetermined value is defined.

 

[peter koch]

Victor Bazarov wrote:
...

If what you say was true, a conforming C++ compiler could translate the
following code:

#include <iostream>
int main()
{
int x;
std::cout << x;
}

to code that formats you disk.
I think it cannot.

And I see nowere in the standard any wording that says that extracting
an undetermined value from a POD is undefined. But I do find wordings
that say that extracting a value is defined and that initializing with
undetermined value is defined.

I believe that C++ in this case has inherited its behaviour from C.
Without wanting to be taken to serious, I believe that accessing
uninitialized storage in the form of char or unsigned integral types
should not be allowed to trap. Accessing it as other types (thus
including plain int) is allowed to trap.

/Peter

 

[Alf P. Steinbach]

* AnalogFile:

#include <iostream>
int main()
{
int x;
std::cout << x;

Error: use of possibly undefined operator<<.
Error: use of uninitialized variable.

}
[snip]

And I see nowere in the standard any wording that says that extracting
an undetermined value from a POD is undefined.
§4.1/1.


But I do find wordings
that say that extracting a value is defined and that initializing with
undetermined value is defined.

No, you don't.