Representative line

As I've mentioned before, it seems that some of my colleages (C developers) aren't to hot with hex. But this one really takes the biscuit:
unsigned long val = ... ;
...
// Test whether top bit is set
if (val & 0x700000) {
...

So is the comment wrong or are they actually testing for the "top" bit and getting false positives, depending on what's in the other 2 bits?

It was supposed to be checking the top bit.

@snoofle said:
So is the comment wrong or are they actually testing for the "top" bit and getting false positives, depending on what's in the other 2 bits?
He ain't even CLOSE to the top bit! He needs to change the 7 to an 8, and add two more zeros! That assumes 32but zeroes. He's testing not the 1st but the 2nd and 3rd bits of a 24bit integer. NOBODY uses 24bit integers.

@AndyCanfield said:
@snoofle said:
So is the comment wrong or are they actually testing for the "top" bit and getting false positives, depending on what's in the other 2 bits?
He ain't even CLOSE to the top bit! He needs to change the 7 to an 8, and add two more zeros! That assumes 32but zeroes. He's testing not the 1st but the 2nd and 3rd bits of a 24bit integer. NOBODY uses 24bit integers.
MySQL does.

@scruff said:
As I've mentioned before, it seems that some of my colleages (C developers) aren't to hot with hex. But this one really takes the biscuit:
unsigned long val = ... ;
...
// Test whether top bit is set
if (val & 0x700000) {
...
<dickweed mode='pedantic'>That's more than one line...</dickweed>

Not a WTF. What if this code is being run on an architecture where long integers are 23 bits wide?
It could happen if the guy reading the CPU design specs was dyslexic!

@toon said:
@AndyCanfield said:
I think he meant nobody that counts.
MySQL does.@snoofle said:
So is the comment wrong or are they actually testing for the "top" bit and getting false positives, depending on what's in the other 2 bits?
He ain't even CLOSE to the top bit! He needs to change the 7 to an 8, and add two more zeros! That assumes 32but zeroes. He's testing not the 1st but the 2nd and 3rd bits of a 24bit integer. NOBODY uses 24bit integers.
Filed under: <FONT color=#698d73>pretty sure that's somebody</FONT>

@Rootbeer said:
What if this code is being run on an architecture where long integers are 23 bits wide?
Last time I checked, 0x7 comprised more than 1 bit, so this would still be wrong.

@scruff said:
It's also using base7.@Rootbeer said:
What if this code is being run on an architecture where long integers are 23 bits wide?
Last time I checked, 0x7 comprised more than 1 bit, so this would still be wrong.

@Sutherlands said:
@scruff said:
It's also using base7.@Rootbeer said:
What if this code is being run on an architecture where long integers are 23 bits wide?
Last time I checked, 0x7 comprised more than 1 bit, so this would still be wrong.
Base8. If it was base7, that'd be 0x10.
(Note: It's entirely possible I'm full of shit on this one, in which case I'll need to sit out the rest of pedantic dickweek)

@Lorne Kates said:
Base8. If it was base7, that'd be 0x10.
(Note: It's entirely possible I'm full of shit on this one, in which case I'll need to sit out the rest of pedantic dickweek)
I'll bring my pedantry to the table then.
0n7[0...], being 7 with some number (O) of 0s, representing a number in base n, is 7 * (n ^ O). The prime factors of which are 7, and some others (PF of n*O).
We're talking about bits, which are in base 2. You can't represent 7 in base 2 with only 1 bit, no matter how hard you try. So 0n7[0...] can't ever be a valid "check top bit" value.

@Lorne Kates said:
Well, if you take into account that what I said was a joke, following on the 23bit wide integer, then yes, please sit the week out. (Although I think it has been determined that it was last week.)Base8. If it was base7, that'd be 0x10.
(Note: It's entirely possible I'm full of shit on this one, in which case I'll need to sit out the rest of pedantic dickweek)

@zelmak said:
@scruff said:
As I've mentioned before, it seems that some of my colleages (C developers) aren't to hot with hex. But this one really takes the biscuit:
unsigned long val = ... ;
...
// Test whether top bit is set
if (val & 0x700000) {
...
<dickweed mode='pedantic'>That's more than one line...</dickweed>
unsigned long val = ... ; if (val & 0x700000) { // Test whether top bit is set
Not anymore.

@scruff said:
@Rootbeer said:
What if this code is being run on an architecture where long integers are 23 bits wide?
Last time I checked, 0x7 comprised more than 1 bit, so this would still be wrong.
What if this code is being run on an architecture where long integers are 21 bits wide?