This topic is now archived and is closed to further replies.

Odd inconsistency with <<.

This topic is 5239 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

    unsigned int thirtyTwo = 32;
    printf("%08x %08x", 0xFF0FFF0F << 32, 0xFF0FFF0F << thirtyTwo);
- Compiled with VC++ 6.0 for x86. - Run on AMD XP1700+. results: 00000000 ff0fff0f results for 33: 00000000 fe1ffe1e There is obviously little that can be done with a compiler if the underlying architecture specifies: VAL << INT = VAL << (INT & (POINTER_SIZE - 1)). unless you want a big speed reduction. Any ideas which result is ANSI-C-correct. I''m assuming ffffffff is x86-correct, otherwise AMD''d be in big trouble. I''m using an annoying workaround at the moment, cos it''s in a time-critical section of my code.

Share this post

Link to post
Share on other sites
left shift by 32 is undefined on 32bit architectures, I believe...

The "correct" value is 0, since you shift all the bits right off the end.

the work around is to do ((x << 16) << 16)

Share this post

Link to post
Share on other sites