Casting long int to int

[KBriggs]

I am trying to debug a confusing bit of stuff in a parallelized code. One possibility for a source of error is that the person who wrote it is using long ints for array indices, then for some reason casts it to an int for a function call, in which it is again used as an array index. Printing it showed that sure enough, it was bigger than INT_MAX before the cast.

Is there a standard way of handling a cast like this? Or is it undefined? Because I am getting different results from run to run, indicating that something undefined is happening, but I am not sure if that is what it would be. Would this cast behave deterministically?

[GReaper]

When you cast something to something else that may be smaller, you may have loss of data. int may be smaller than long.

EDIT: That depends mostly on the CPU.

[KBriggs]

Assuming that int is smaller than long, what will the result of the cast of a long int to int, given that the number is bigger than INT_MAX before the cast?

Is that what you meant would be CPU dependent?

EDIT: question is horribly phrase, sorry, my brain is fried atm. Hopefully you understand.

[GReaper]

Assuming that int is smaller than long, what will the result of the cast of a long int to int, given that the number is bigger than INT_MAX before the cast?

Is that what you meant would be CPU dependent?

The extra bits will be thrown away. Yes, that's what i mean.

EDIT: It's OK.

[CommonTater]

Assuming that int is smaller than long, what will the result of the cast of a long int to int, given that the number is bigger than INT_MAX before the cast?

Is that what you meant would be CPU dependent?

Ok... lets asume as Sipher says, that you have a long int = 64 bits and an int = 32 bits...

What happens to the most significant 32 bits when you typecast?

They're simply discarded.

So here you are looking at an array (and a darned big one) where an operation is being performed on the wrong index points.

It is programming folly to typecast down in size like that. In fact, I'm surprised there weren't a whole cascade of compiler warnings about it.

[KBriggs]

Sigh... so am I.

And the weirdest thing is that this code has worked in the past for far larger arrays, and given perfectly reasonable results every time.


EDIT: printing INT_MAX on the system here gives 2147483647, and the numbers I am working with certainly never get even close to that.

Could someone take me through a quick example? Say my (long int) is 5000. I cast this to int. What is it now?

[GReaper]

Could someone take me through a quick example? Say my (long int) is 5000. I cast this to int. What is it now?

Surely the same. Everything between -32768 to 32767 for signed and 0 to 65535 for unsigned is surely preserved in an int.
( Since the standard says that short is at least 2 bytes and that int can't be smaller than short )

[KBriggs]

In that case, I think my problem must lie elsewhere. Not that this isn't wrong, just couldn't be causing this trouble if it preserves values like that.

[adeyblue]

If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.

In English:
As long as what you cast from long int is within range of a plain int, everything is the same. Otherwise, consult your compiler's documentation because we can't make up our minds what should happen

[GReaper]

C++ 2003 Standard ?! o_O Isn't this thread about C?

EDIT: Yeah, 600 posts!!!

[cas]

The rules for converting between integers are, in part, as follows:

When a value with integer type is converted to another integer type ..., if the value can be represented by the new type, it is unchanged.
...
[If] 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.

C89 is the same except that there is no mention of a signal being raised.

So for long->int, if the value fits into an int, it's stored as you would expect. Otherwise, it depends on the implementation--which is required, by the standard, to document how the conversion happens.

[KBriggs]

Thanks all.

Seems it should not be a problem for the current run, so I am back to my nodes not communicating for some reason ^_^

If it turns out that this was the issue, I'll post details when I solve it.

[CommonTater]

Sigh... so am I.

And the weirdest thing is that this code has worked in the past for far larger arrays, and given perfectly reasonable results every time.


EDIT: printing INT_MAX on the system here gives 2147483647, and the numbers I am working with certainly never get even close to that.

Could someone take me through a quick example? Say my (long int) is 5000. I cast this to int. What is it now?

Probably still 5000...

However if it was 2,147,483,650 you would end up with -2, essentially the result of anding it with 0xFFFFFFFF ...

[GokhanK]

Ok... lets asume as Sipher says, that you have a long int = 64 bits and an int = 32 bits....

I know int is dependent to CPU? Is long int too?

I didn't know it, can someone suggest me an online source to read about data types and how they change?

[anduril462]

Reading the C standards is always a good place to find info like this: C Draft Standards.