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

  2. jeff

    Jordan Abel Guest

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

  3. jeff said:
    a can't overflow. If the value of a exceeds LONG_MAX, the value of b is
    undefined.
     
    Richard Heathfield, Dec 27, 2005
    #3
  4. 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, Dec 27, 2005
    #4
  5. jeff

    Jordan Abel Guest

    That's not considered "integer overflow"?

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

    my mistake, it's not
     
    Jordan Abel, Dec 27, 2005
    #5
  6. jeff

    Jack Klein Guest

    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.
    '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.
    You're welcome.
     
    Jack Klein, Dec 27, 2005
    #6
  7. jeff

    Jack Klein Guest

    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, Dec 27, 2005
    #7
  8. jeff

    Jack Klein Guest

    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, Dec 27, 2005
    #8
  9. Jack Klein said:
    Jack, I sit corrected. Thank you.
     
    Richard Heathfield, Dec 27, 2005
    #9
  10. 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

    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, Dec 27, 2005
    #11
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.