Is it UB once it's an L-value?

[Tomás]

Anything wrong with the following code?:
#include <cstdlib>

int main()
{
for (unsigned i = 0; i != 1000; ++i)
{
int *p = reinterpret_cas t<int*>( std::rand() );
}
}
In the code, I'm creating an L-value pointer whose value is invalid.
However, the invalid memory address is never accessed.

Does the program exhibit Undefined Behaviour?

-Tomás

[Erik Wikström]

On 2006-05-28 17:22, Tomás wrote:

Anything wrong with the following code?:
#include <cstdlib>

int main()
{
for (unsigned i = 0; i != 1000; ++i)
{
int *p = reinterpret_cas t<int*>( std::rand() );
}
}
In the code, I'm creating an L-value pointer whose value is invalid.
However, the invalid memory address is never accessed.

Does the program exhibit Undefined Behaviour?

Can't see why, if just having an invalid pointer was enough to cause UB
then the following code would be a problem:

int main()
{
int *p;
return 0;
}

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

[Phlip]

Tomás wrote:

int *p = reinterpret_cas t<int*>( std::rand() ); Does the program exhibit Undefined Behaviour?

Yes, and sketching the result in hardware will illustrate why.

I can conceive of a CPU that efficiently stores pointers in special
registers, and which faults if a bit pattern copies into such a register
that doesn't refer to valid memory. So a compiler must compile your p
optimistically, and use this register even though you never dereference p.

This is among the reasons why accessing a deleted pointer is undefined.

I think the Motorola 68000 faults if an An register gets an odd number...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Phlip]

Erik Wikström wrote:

Can't see why, if just having an invalid pointer was enough to cause UB
then the following code would be a problem: int *p;

You copied no value in. So in my register example, the compiler reserved the
register and did not change its current value. So the surrounding opcodes
must keep that value healthy.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Kai-Uwe Bux]

Phlip wrote:

Tomás wrote:

int *p = reinterpret_cas t<int*>( std::rand() );

Does the program exhibit Undefined Behaviour?

Yes, and sketching the result in hardware will illustrate why.

[elaboration about a hypothetical implementation snipped]

No. The behavior is not undefined but implementation defined:

[5.2.10/5] (expr.reinterpr et.cast)

A value of integral type or enumeration type can be explicitly converted to
a pointer. A pointer converted to an integer of sufficient size (if any
such exists on the implementation) and back to the same pointer type will
have its original value; mappings between pointers and integers are
otherwise implementation-defined.
Best

Kai-Uwe Bux

[Tomás]

Phlip posted:

Yes, and sketching the result in hardware will illustrate why.

I can conceive of a CPU that efficiently stores pointers in special
registers, and which faults if a bit pattern copies into such a
register that doesn't refer to valid memory. So a compiler must
compile your p optimistically, and use this register even though you
never dereference p.

This is among the reasons why accessing a deleted pointer is
undefined.

I think the Motorola 68000 faults if an An register gets an odd
number...

But looking at it from an "official" viewpoint, why does it exhibit
undefined behaviour? Is it because I've turned an invalid pointer value
into an L-value?

Does the following code exhibit undefined behaviour:

#include <cstdlib>

int main()
{
reinterpret_cas t<int*>( std::rand() );
}
-Tomás

[Tomás]

Kai-Uwe Bux posted:

[5.2.10/5] (expr.reinterpr et.cast)

A value of integral type or enumeration type can be explicitly
converted to a pointer. A pointer converted to an integer of
sufficient size (if any such exists on the implementation) and back to
the same pointer type will have its original value; mappings between
pointers and integers are otherwise implementation-defined.

My query has nothing to do with integer-to-pointer conversion -- it's to
do with storing an invalid pointer value in a pointer variable.
-Tomás

[Phlip]

Kai-Uwe Bux wrote:

No. The behavior is not undefined but implementation defined:

[5.2.10/5] (expr.reinterpr et.cast)

A value of integral type or enumeration type can be explicitly converted
to
a pointer. A pointer converted to an integer of sufficient size (if any
such exists on the implementation) and back to the same pointer type will
have its original value; mappings between pointers and integers are
otherwise implementation-defined.

He ain't converting from a pointer. rand() returns an int.

But while you have the Standard out, answer his next question; I don't know
the answer! ;-)

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Tomás]

Tomás posted:

Anything wrong with the following code?:

For the purpose of this example, assume that the resultant pointer value
gotten from converting the int is an actual valid pointer value (i.e. you
won't get any trapping values or whatever).
-Tomás

[Tomás]

Tomás posted:

Anything wrong with the following code?:

Actually scrub all that. I've thought of a much better example.

Is the following UB:

int main()
{
double array[4];

double *p = array + 7;
}
And what about the following:

int main()
{
double array[4];

array + 7;
}

-Tomás