Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   cast unsigned long to long (http://www.velocityreviews.com/forums/t440668-cast-unsigned-long-to-long.html)

 jeff 12-27-2005 02:13 PM

cast unsigned long to long

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

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

 Jordan Abel 12-27-2005 02:21 PM

Re: cast unsigned long to long

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

undefined.

 Richard Heathfield 12-27-2005 02:38 PM

Re: cast unsigned long to long

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 12-27-2005 04:53 PM

Re: cast unsigned long to long

"jeff" <xiayu02@gmail.com> 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) kst-u@mib.org <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 12-27-2005 04:56 PM

Re: cast unsigned long to long

On 2005-12-27, Keith Thompson <kst-u@mib.org> wrote:
> "jeff" <xiayu02@gmail.com> 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 12-27-2005 08:14 PM

Re: cast unsigned long to long

On 27 Dec 2005 06:13:19 -0800, "jeff" <xiayu02@gmail.com> 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 12-27-2005 08:18 PM

Re: cast unsigned long to long

On Tue, 27 Dec 2005 14:21:12 +0000 (UTC), Jordan Abel
<jmabel@purdue.edu> wrote in comp.lang.c:

> On 2005-12-27, jeff <xiayu02@gmail.com> 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 12-27-2005 08:19 PM

Re: cast unsigned long to long

On Tue, 27 Dec 2005 14:38:56 +0000 (UTC), Richard Heathfield
<invalid@invalid.invalid> 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 12-27-2005 09:21 PM

Re: cast unsigned long to long

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 12-27-2005 10:39 PM

Re: cast unsigned long to long

Jack Klein <jackklein@spamcop.net> 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?

All times are GMT. The time now is 10:12 PM.