cast unsigned long to long

[jeff]

unsigned long a = ...;
long b = (long)a;

while a overflows, what is the result of b?
Thank you.

 

[Jordan Abel]

unsigned long a = ...;
long b = (long)a;

while a overflows, what is the result of b?
Thank you.

undefined.

 

[Richard Heathfield]

jeff said:

unsigned long a = ...;
long b = (long)a;

while a overflows, what is the result of b?

a can't overflow. If the value of a exceeds LONG_MAX, the value of b is
undefined.

 

[Keith Thompson]

unsigned long a = ...;
long b = (long)a;

while a overflows, what is the result of b?

The cast is unnecessary; the declaration
long b = a;
is equivalent, since there's an implicit conversion. (Most casts are
unnecessary.)

If a conversion to a signed integer type overflows, "either the result
is implementation-defined or an implementation-defined signal is
raised" (C99 6.3.1.3p3). I think the permission to raise a signal is
new in C99; in C90, you just get an implementation-defined result.
(No, it's not undefined.)

"Implementation-defined" means that your implementation is required to
document it, but you shouldn't depend on this since it's likely to
vary from one implementation to another, making your code
non-portable.

Note that this is different from what happens on artithmetic overflow,
which invokes undefined behavior for signed types.

 

[Jordan Abel]

The cast is unnecessary; the declaration
long b = a;
is equivalent, since there's an implicit conversion. (Most casts are
unnecessary.)

If a conversion to a signed integer type overflows, "either the result
is implementation-defined or an implementation-defined signal is
raised" (C99 6.3.1.3p3). I think the permission to raise a signal is
new in C99; in C90, you just get an implementation-defined result.
(No, it's not undefined.)

That's not considered "integer overflow"?

An example of undefined behavior is the behavior on integer overflow.

my mistake, it's not

 

[Jack Klein]

unsigned long a = ...;
long b = (long)a;

The cast is completely unnecessary and gains you nothing at all. An
assignment between two different types where assignment is permitted
causes an implicit conversion of the source type to the destination
type. So when you assign 'a' to 'b', there is an implicit and
automatic conversion of the value of 'a' to signed long. Adding a
cast to specify an explicit conversion that is being performed
automatically only obfuscates your code.

while a overflows, what is the result of b?

'a' is an unsigned long, and unsigned types can't overflow. I suppose
the question you are really asking is, what happens if 'a' contains a
value larger than LONG_MAX.

In that case, either 'b' receives an implementation-defined value or
an implementation-defined signal is raised.

Thank you.

You're welcome.

 

[Jack Klein]

undefined.

That's not correct:

====
6.3 Conversions
6.3.1 Arithmetic operands
6.3.1.3 Signed and unsigned integers

1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type, it
is unchanged.

2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.

3 Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined or an
implementation-defined signal is raised.
====

The "implementation-defined signal" option is new with C99. Under
C89/90, the result was always an implementation-defined value, and
never undefined behavior.

 

[Jack Klein]

jeff said:


a can't overflow. If the value of a exceeds LONG_MAX, the value of b is
undefined.

That's not correct:

====
6.3 Conversions
6.3.1 Arithmetic operands
6.3.1.3 Signed and unsigned integers

1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type, it
is unchanged.

2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.

3 Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined or an
implementation-defined signal is raised.
====

The "implementation-defined signal" option is new with C99. Under
C89/90, the result was always an implementation-defined value, and
never undefined behavior.

 

[Richard Heathfield]

Jack Klein said:

Under
C89/90, the result was always an implementation-defined value, and
never undefined behavior.

Jack, I sit corrected. Thank you.

 

[Christian Bau]

'a' is an unsigned long, and unsigned types can't overflow. I suppose
the question you are really asking is, what happens if 'a' contains a
value larger than LONG_MAX.

In that case, either 'b' receives an implementation-defined value or
an implementation-defined signal is raised.

Do you know if it is implementation-defined which one will happen? So an
implementation has to specify that either there will _always_ be an
implementation defined value or _always_ an implementation-defined
signal?

 

[Jack Klein]

Do you know if it is implementation-defined which one will happen? So an
implementation has to specify that either there will _always_ be an
implementation defined value or _always_ an implementation-defined
signal?

No, I don't. The "implementation-defined signal" option did not exist
prior to C99. The one time I can remember the question being asked on
comp.std.c, no one who responded claimed to know of any such system.
One committee member wrote something about not constraining future
implementations.

As to whether the implementation is required to do the same thing for
all integer types, I am not so sure.

Consider an architecture with 32 bit registers that implemented
int64_t and uint64_t using its floating point hardware, which is not
particularly far-fetched since one could do this on anything in the
x86 family from the 486DX on up.

Such an implementation could specify the "expected"
implementation-defined behavior of bit truncation for the types up to
and including int32_t, but specify that it would throw a signal on
converting an out-of-range double to an int64_t. If the floating
point hardware generated an exception on out-of-range conversion, the
compiler run time would need to trap it and throw a C signal.

I have no idea whether such an implementation ever has or ever will
exist.