StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7603548
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2011-09-29T21:22:59.067
FavoriteCount
0
LastActivityDate
2011-09-30T06:39:59.930
LastEditDate
2011-09-30T06:39:59.930
LastEditorUserId
827263
OwnerUserId
827263
ParentId
7603279
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
It's very probably not attempting to shift by some large number of bits. <code>INT_MAX</code> on your system is probably <code>2**31-1</code>, or <code>0x7fffffff</code> (I'm using <code>**</code> to denote exponentiation). If that's the case, then In the declaration: <pre><code>int b = 0x80000000; </code></pre> (which was missing a semicolon in the question; please copy-and-paste your exact code) the constant <code>0x80000000</code> is of type <code>unsigned int</code>, not <code>int</code>. The value is implicitly converted to <code>int</code>. Since the result is outside the bounds of <code>int</code>, the result is implementation-defined (or, in C99, may raise an implementation-defined signal, but I don't know of any implementation that does that). The most common way this is done is to reinterpret the bits of the unsigned value as a 2's-complement signed value. The result in this case is <code>-2**31</code>, or <code>-2147483648</code>. So the behavior isn't undefined because you're shifting by value that equals or exceeds the width of type <code>int</code>, it's undefined because you're shifting by a (very large) negative value. Not that it matters, of course; undefined is undefined. NOTE: The above assumes that <code>int</code> is 32 bits on your system. If <code>int</code> is wider than 32 bits, then most of it doesn't apply (but the behavior is still undefined). If you really wanted to attempt to shift by <code>0x80000000</code> bits, you could do it like this: <pre><code>unsigned long b = 0x80000000; unsigned long a = 1 >> b; // *still* undefined </code></pre> <code>unsigned long</code> is guaranteed to be big enough to hold the value <code>0x80000000</code>, so you avoid part of the problem. Of course, the behavior of the shift is just as undefined as it was in your original code, since 0x80000000 is greater than or equal to the width of <code>unsigned long</code>. (Unless your compiler has a really big <code>unsigned long</code> type, but no real-world compiler does that.) The only way to avoid undefined behavior is not to do what you're trying to do. It's possible<strike>, but vanishingly unlikely,</strike> that your original code's behavior is not undefined. That can only happen if the implementation-defined conversion of <code>0x80000000</code> from <code>unsigned int</code> to <code>int</code> yields a value in the range 0 .. 31. IF <code>int</code> is smaller than 32 bits, the conversion is likely to yield 0.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhy does (1 >> 0x80000000) == 1?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USKeith Thompson
UserOwnerUserId
1. USKeith Thompson
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COThe last paragraph is not so vanishingly unlikely - it would be quite likely on a system with 16 bit `int`, which is far from unheard-of.
 singulars
 PostPostId
 PO
 UserUserId
 UScaf
2. CO@caf: Quite right, I should have thought of that.
 singulars
 PostPostId
 PO
 UserUserId
 USKeith Thompson

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.