cast unsigned long to long

Discussion in 'C Programming' started by jeff, Dec 27, 2005.

  1. jeff

    jeff Guest

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

    while a overflows, what is the result of b?
    Thank you.
     
    jeff, Dec 27, 2005
    #1
    1. Advertising

  2. jeff

    Jordan Abel Guest

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


    undefined.
     
    Jordan Abel, Dec 27, 2005
    #2
    1. Advertising

  3. 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)
     
    Richard Heathfield, Dec 27, 2005
    #3
  4. "jeff" <> 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.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 27, 2005
    #4
  5. jeff

    Jordan Abel Guest

    On 2005-12-27, Keith Thompson <> wrote:
    > "jeff" <> 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.
    >
     
    Jordan Abel, Dec 27, 2005
    #5
  6. jeff

    Jack Klein Guest

    On 27 Dec 2005 06:13:19 -0800, "jeff" <> 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
    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
    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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 27, 2005
    #6
  7. jeff

    Jack Klein Guest

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

    > On 2005-12-27, jeff <> 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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 27, 2005
    #7
  8. jeff

    Jack Klein Guest

    On Tue, 27 Dec 2005 14:38:56 +0000 (UTC), Richard Heathfield
    <> 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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 27, 2005
    #8
  9. 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)
     
    Richard Heathfield, Dec 27, 2005
    #9
  10. In article <>,
    Jack Klein <> 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?
     
    Christian Bau, Dec 27, 2005
    #10
  11. jeff

    Jack Klein Guest

    On Tue, 27 Dec 2005 22:39:54 +0000, Christian Bau
    <> wrote in comp.lang.c:

    > In article <>,
    > Jack Klein <> 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?


    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.

    --
    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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Dec 27, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George Marsaglia

    Assigning unsigned long to unsigned long long

    George Marsaglia, Jul 8, 2003, in forum: C Programming
    Replies:
    1
    Views:
    686
    Eric Sosman
    Jul 8, 2003
  2. Replies:
    1
    Views:
    454
    Diez B. Roggisch
    Jun 1, 2005
  3. sridhar

    comparing unsigned long and unsigned int

    sridhar, Nov 1, 2004, in forum: C Programming
    Replies:
    6
    Views:
    451
    J. J. Farrell
    Nov 3, 2004
  4. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,201
    Peter Shaggy Haywood
    Sep 20, 2005
  5. pozz
    Replies:
    12
    Views:
    748
    Tim Rentsch
    Mar 20, 2011
Loading...

Share This Page