Velocity Reviews > cast unsigned long to long

cast unsigned long to long

jeff
Guest
Posts: n/a

 12-27-2005

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

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

Jordan Abel
Guest
Posts: n/a

 12-27-2005
On 2005-12-27, jeff <(E-Mail Removed)> wrote:
>
> unsigned long a = ...;
> long b = (long)a;
>
> while a overflows, what is the result of b?
> Thank you.

undefined.

Richard Heathfield
Guest
Posts: n/a

 12-27-2005
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Keith Thompson
Guest
Posts: n/a

 12-27-2005
"jeff" <(E-Mail Removed)> writes:
> 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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Jordan Abel
Guest
Posts: n/a

 12-27-2005
On 2005-12-27, Keith Thompson <(E-Mail Removed)> wrote:
> "jeff" <(E-Mail Removed)> writes:
>> 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.)

That's not considered "integer overflow"?

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

my mistake, it's not

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

Jack Klein
Guest
Posts: n/a

 12-27-2005
On 27 Dec 2005 06:13:19 -0800, "jeff" <(E-Mail Removed)> wrote in
comp.lang.c:

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

> 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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Jack Klein
Guest
Posts: n/a

 12-27-2005
On Tue, 27 Dec 2005 14:21:12 +0000 (UTC), Jordan Abel
<(E-Mail Removed)> wrote in comp.lang.c:

> On 2005-12-27, jeff <(E-Mail Removed)> wrote:
> >
> > unsigned long a = ...;
> > long b = (long)a;
> >
> > while a overflows, what is the result of b?
> > Thank you.

>
> 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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Jack Klein
Guest
Posts: n/a

 12-27-2005
On Tue, 27 Dec 2005 14:38:56 +0000 (UTC), Richard Heathfield
<(E-Mail Removed)> wrote in comp.lang.c:

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

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
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Richard Heathfield
Guest
Posts: n/a

 12-27-2005
Jack Klein said:

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

Jack, I sit corrected. Thank you.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Christian Bau
Guest
Posts: n/a

 12-27-2005
In article <(E-Mail Removed)>,
Jack Klein <(E-Mail Removed)> wrote:

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