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

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

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_positiv e_value_support ed_by_the_small er_range_type]


Regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

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.

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_positiv e_value_support ed_by_the_small er_range_type]

Regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

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,

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

in a union with a value in
[0, maximum_positiv e_value_support ed_by_the_small er_range_type]

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.

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

[Ioannis Vranos]

Rob Williscroft wrote:

which makes the behaviour well-defined for signed and unsigned integer
types in a union with a value in
[0, maximum_positiv e_value_support ed_by_the_small er_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]

On Wed, 30 Jun 2004 02:16:07 +0300, Ioannis Vranos
<iv*@guesswh.at .grad.com> wrote:

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.

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_positiv e_value_support ed_by_the_small er_range_type]

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

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Ioannis Vranos]

tom_usenet wrote:

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]

JKop <NU**@NULL.NULL > wrote:

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).
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:

It's undefined behaviour to read any member of a union other than
the one that was most recently assigned

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