445,918 Members | 2,279 Online
Need help? Post your question and get tips & solutions from a community of 445,918 IT Pros & Developers. It's quick & easy.

# cast unsigned long to long

 P: n/a unsigned long a = ...; long b = (long)a; while a overflows, what is the result of b? Thank you. Dec 27 '05 #1
10 Replies

 P: n/a 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. Dec 27 '05 #2

 P: n/a 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) Dec 27 '05 #3

 P: n/a "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) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Dec 27 '05 #4

 P: n/a 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. Dec 27 '05 #5

 P: n/a 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/~a...FAQ-acllc.html Dec 27 '05 #6

 P: n/a 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/~a...FAQ-acllc.html Dec 27 '05 #7

 P: n/a 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/~a...FAQ-acllc.html Dec 27 '05 #8

 P: n/a 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) Dec 27 '05 #9

 P: n/a 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? Dec 27 '05 #10

 P: n/a 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/~a...FAQ-acllc.html Dec 27 '05 #11

### This discussion thread is closed

Replies have been disabled for this discussion.