Overflow Underflow

[Rob Williscroft]

Ioannis Vranos wrote in in
comp.lang.c++:

Rob Williscroft wrote:




Then JKOP is right!


#include <iostream>


union whatever
{
unsigned u;
signed i;
};


int main()
{
using namespace std;

whatever nice;

nice.i=-1;

cout<<nice.u<<" "<<static_cast<unsigned>(-1)<<endl;
}


Based on the standard nice.u above will always be equal to
numeric_limits<unsigned>::max()!

No on a 1's complement machine (say 16 bit for example -1 will
be represented in binary as 10000000 00000001 high bit (sign bit)
and byte first. unsigned( -1 ) is 11111111 11111111 which is
std::numeric_limits< unsigned >::max().

You must read the union member that was last assigned.

3.9.1/3 says that INT_MAX 01111111 1111111 has the same value
representation in signed and unsigned.

Doing:

nice.i = INT_MAX;
cout << nice.u;

is still UB, but in practice its only UB because the standard
says so. In theory (for example) a compiler could diagnose the
UB and refuse to compile, its UB, its free to *anything* it wants
and still be a conforming compiler.

Rob.

 

[Ioannis Vranos]

Based on the standard nice.u above will always be equal to
numeric_limits<unsigned>::max()!

Actually the standard states:



"For each of the signed integer types, there exists a corresponding (but
different) unsigned integer type: “unsigned char”, “unsigned short int”,
“unsigned int”, and “unsigned long int,” each of which occupies the same
amount of storage and has the same alignment requirements (3.9) as the
corresponding signed integer type 40) ; that is, each signed integer
type has the same object representation as its corresponding unsigned
integer type. The range of nonnegative values of a signed integer type
is a subrange of the corresponding unsigned integer type, and the value
representation of each corresponding signed/unsigned type shall be the same.

....

40) See 7.1.5.2 regarding the correspondence between types and the
sequences of type-specifiers that designate them."



So the above leaves it possible the signed(-1) and unsigned(-1) to have
a different value representation. signed(-2) and unsigned(-2) to have a
different representation and so on.


So as far as I can get it, the union thing is not guaranteed to work.
Any comments?






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

No on a 1's complement machine (say 16 bit for example -1 will
be represented in binary as 10000000 00000001 high bit (sign bit)
and byte first. unsigned( -1 ) is 11111111 11111111 which is
std::numeric_limits< unsigned >::max().

You must read the union member that was last assigned.

3.9.1/3 says that INT_MAX 01111111 1111111 has the same value
representation in signed and unsigned.

Yes.



Doing:

nice.i = INT_MAX;
cout << nice.u;

is still UB, but in practice its only UB because the standard
says so.

What do you mean? For non-negative values which are in range of both
types, they must have the same value representation.






Regards,

Ioannis Vranos

 

[Rob Williscroft]

Ioannis Vranos wrote in in
comp.lang.c++:

What do you mean? For non-negative values which are in range of both
types, they must have the same value representation.

Yes, what I mean I said just after the bit you quoted, here it is
again:

is still UB, but in practice its only UB because the standard
says so. In theory (for example) a compiler could diagnose the
UB and refuse to compile, its UB, its free to *anything* it wants
and still be a conforming compiler.

Rob.

 

[Ioannis Vranos]

Yes, what I mean I said just after the bit you quoted, here it is
again:

is still UB, but in practice its only UB because the standard
says so.

Yes I meant, "where does the standard say so"?






Regards,

Ioannis Vranos

 

[Old Wolf]

Then JKOP is right!
Hardly

#include <iostream>

union whatever
{
unsigned u;
signed i;
};

int main()
{
using namespace std;
whatever nice;
nice.i=-1;
cout<<nice.u<<" "<<static_cast<unsigned>(-1)<<endl;
}

It's undefined behaviour to read any member of a union other than
the one that was most recently assigned (with the exception of the
case where the member read, and the most recently assigned member,
are 'struct's with a common initial sequence, and you read one of
the members of that common initial sequence).

Based on the standard nice.u above will always be equal to
numeric_limits<unsigned>::max()!

C and C++ work on values, not representations. -1 when static_cast
to an unsigned type will always be the maximum value of that type,
regardless of representation.

On the other hand, the representation of (int)-1 and (unsigned)-1
need not be the same (AFAICS), so even if the union example was
not UB, it still would not 'work'.

I suspect that reinterpret_cast<> will do what you are trying to do
with the union example (I don't have a 1's complement machine to
test it on though..)

 

[JKop]

Old Wolf posted:

It's undefined behaviour to read any member of a union other than
the one that was most recently assigned (with the exception of the
case where the member read, and the most recently assigned member,
are 'struct's with a common initial sequence, and you read one of
the members of that common initial sequence).

I know it's Undefined Behaviour to read from a double or a float without
prior initialization, ie.


double a;
float b;

a += 5.6;

b -= 6.2;


But... is it Undefined Behaviour to read from an uninitialized int? If
*not*, then contrary to you last post, there's nothing wrong with the
following:

union Chase
{
char black[sizeof(long)];
unsigned long blue;
};

int main()
{
Chase pursuit;

pursuit.black[0] = 5;
pursuit.black[1] = 2;
pursuit.black[2] = 6;
pursuit.black[3] = 88;

pursuit.blue += 4;
}


I last set it via black, but still there's nothing wrong with accessing it
via blue.


-JKop

 

[Ioannis Vranos]

But... is it Undefined Behaviour to read from an uninitialized int?

Actually it is.


Here are some definitions from the Standard:


1.3.12 undefined behavior
behavior, such as might arise upon use of an erroneous program construct
or erroneous data, for which this International Standard imposes no
requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition
of behavior. [Note: permissible undefined behavior ranges from ignoring
the situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
message), to terminating a translation or execution (with the issuance
of a diagnostic message). Many erroneous program constructs do not
engender undefined behavior; they are required to be diagnosed. ]


1.3.13 unspecified behavior
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs. [Note: usually, the range of possible
behaviors is delineated by this International Standard. ]"



As i have said in another message of mine, the union thing is not
guaranteed to work for values other than positive ones in the range
[0,maximum_positive_one_supported_by_the_smaller_range_type].






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

But... is it Undefined Behaviour to read from an uninitialized int?

Actually it is.


Here are some definitions from the Standard:


1.3.12 undefined behavior
behavior, such as might arise upon use of an erroneous program construct
or erroneous data, for which this International Standard imposes no
requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition
of behavior. [Note: permissible undefined behavior ranges from ignoring
the situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
message), to terminating a translation or execution (with the issuance
of a diagnostic message). Many erroneous program constructs do not
engender undefined behavior; they are required to be diagnosed. ]


1.3.13 unspecified behavior
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs. [Note: usually, the range of possible
behaviors is delineated by this International Standard. ]"



As i have said in another message of mine, the union thing is not
guaranteed to work for values other than positive ones in the range
[0,maximum_positive_one_supported_by_the_smaller_range_type].

And another interesting behaviour is:

1.3.5 implementation-defined behavior
behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation shall document.






Regards,

Ioannis Vranos

 

[Rob Williscroft]

Ioannis Vranos wrote in in
comp.lang.c++:

Yes I meant, "where does the standard say so"?

Section 9 Classes, 9.5 Unions, paragraph 1.

Rob.

 

[Ioannis Vranos]

Section 9 Classes, 9.5 Unions, paragraph 1.

I read that and I did not find something that would cause undefined
behaviour, in the contrary it says:

"The size of a union is sufficient to contain the largest of its data
members. Each data member is allocated as if it were the sole member
of a struct."


which makes the behaviour well-defined for signed and unsigned integer
types in a union with a value in
[0, maximum_positive_value_supported_by_the_smaller_range_type]






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

I read that and I did not find something that would cause undefined
behaviour, in the contrary it says:

"The size of a union is sufficient to contain the largest of its data
members. Each data member is allocated as if it were the sole member
of a struct."


which makes the behaviour well-defined for signed and unsigned integer
types

of the same size,

in a union with a value in
[0, maximum_positive_value_supported_by_the_smaller_range_type]

Regards,

Ioannis Vranos

 

[Ioannis Vranos]

of the same size,

of similar types (e.g. signed int with unsigned int)

in a union with a value in
[0, maximum_positive_value_supported_by_the_smaller_range_type]

Regards,

Ioannis Vranos

 

[Rob Williscroft]

Ioannis Vranos wrote in in
comp.lang.c++:

I read that and I did not find something that would cause undefined
behaviour, in the contrary it says:

The section (9.5) defines *all* the behaviour, that which it doesen't
define is *undefined*.

"The size of a union is sufficient to contain the largest of its data
members. Each data member is allocated as if it were the sole member
of a struct."

Irrelevant, you may only inspect the member that was most reciently
assigned too, *nothing* else is *defined* by the standard.

which makes the behaviour well-defined for signed and unsigned integer
types in a union with a value in
[0, maximum_positive_value_supported_by_the_smaller_range_type]

Again:

.... In theory (for example) a compiler could diagnose the
UB and refuse to compile, its UB, its free to *anything* it wants
and still be a conforming compiler.

Also an implementation could have "type" bits in the object
representation of its signed and unsigned types, simply
reading the wrong union member could cause the CPU to fault.

If it *isn't* defined its undefined, whats so difficult
to understand about this.

Rob.

 

[Ioannis Vranos]

which makes the behaviour well-defined for signed and unsigned integer
types in a union with a value in
[0, maximum_positive_value_supported_by_the_smaller_range_type]

Again:

.... In theory (for example) a compiler could diagnose the
UB and refuse to compile, its UB, its free to *anything* it wants
and still be a conforming compiler.

Also an implementation could have "type" bits in the object
representation of its signed and unsigned types, simply
reading the wrong union member could cause the CPU to fault.

If it *isn't* defined its undefined, whats so difficult
to understand about this.

The only thing that makes you right and this undefined is the wording of
the standard:

"The size of a union is sufficient to contain the largest of its data
members."



The "sufficient" makes it undefined. If it were "equal to the largest of
its data members", it would not be undefined in any way.


So you are right, it is undefined, because in theory it can be larger
than the largest member and place them in a slightly different location.






Regards,

Ioannis Vranos

 

[tom_usenet]

Section 9 Classes, 9.5 Unions, paragraph 1.

I read that and I did not find something that would cause undefined
behaviour, in the contrary it says:

"The size of a union is sufficient to contain the largest of its data
members. Each data member is allocated as if it were the sole member
of a struct."


which makes the behaviour well-defined for signed and unsigned integer
types in a union with a value in
[0, maximum_positive_value_supported_by_the_smaller_range_type]

Did you not read the very first sentence of 9.5/1? Seems pretty
clear...

Tom

 

[Ioannis Vranos]

Did you not read the very first sentence of 9.5/1? Seems pretty
clear...

Yes you are right, I just noticed it.






Regards,

Ioannis Vranos

 

[Old Wolf]

Old Wolf posted:


But... is it Undefined Behaviour to read from an uninitialized int?

Yes. It's UB to access an indeterminate value, and uninitialized
variables all have indeterminate value.

If *not*, then contrary to you last post, there's nothing wrong with the
following:

union Chase
{
char black[sizeof(long)];
unsigned long blue;
};
pursuit.black[0] = 5;
pursuit.black[1] = 2;
pursuit.black[2] = 6;
pursuit.black[3] = 88;
pursuit.blue += 4;

This is nothing to do with reading from uninitialized variables.
Perhaps you missed what I said above:

Your example is a union, and you assign 'black' and then read 'blue'.
Your code is still UB even if you assign something to blue before
you assign to black.

If you want an exact reference in the standard, do a text search
for 'union' on your pirate copy

 

[JKop]

Old Wolf posted:

If you want an exact reference in the standard, do a text search
for 'union' on your pirate copy

I don't have a copy, hence the requests.


-JKop