Overflow Underflow

[JKop]

union SignedChoice{
long with_sign;
unsigned long without_sign;
};
int main()
{
SignedChoice data;

data.with_sign = -1;
//Right now, does the C++ Standard guarantee that
//data.without_si gn == MAX_ULONGINT?

//Similarly:

data.without_si gn = MAX_ULONGINT;

//Is data.with_sign now definitely == -1?

}
Is there any other interesting facts yous can give me?

-JKop

[Rob Williscroft]

Ioannis Vranos wrote in news:cb******** ***@ulysses.noc .ntua.gr in
comp.lang.c++:

Rob Williscroft wrote:

3.9.1/3

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_li mits< 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.
--
http://www.victim-prime.dsl.pipex.com/

[Ioannis Vranos]

Ioannis Vranos wrote:

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]

Rob Williscroft wrote:

#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;
}
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_li mits< 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 news:cb******** ***@ulysses.noc .ntua.gr in
comp.lang.c++:

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.

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.
--
http://www.victim-prime.dsl.pipex.com/

[Ioannis Vranos]

Rob Williscroft wrote:

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]

Ioannis Vranos <iv*@guesswh.at .grad.com> wrote:

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

JKop wrote:

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_posit ive_one_support ed_by_the_small er_range_type].


Regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

JKop wrote:

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_posit ive_one_support ed_by_the_small er_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 news:cb******** ***@ulysses.noc .ntua.gr in
comp.lang.c++:

Rob Williscroft wrote:

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"?

Section 9 Classes, 9.5 Unions, paragraph 1.

Rob.
--
http://www.victim-prime.dsl.pipex.com/