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 32-but zeroes. He's testing not the 1st but the 2nd and 3rd bits of a 24-bit 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 32-but zeroes. He's testing not the 1st but the 2nd and 3rd bits of a 24-bit 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:

    @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 32-but zeroes. He's testing not the 1st but the 2nd and 3rd bits of a 24-bit integer. NOBODY uses 24bit integers.

     

    MySQL does.

    Filed under: <FONT color=#698d73>pretty sure that's somebody</FONT> 

    I think he meant nobody that counts.



  • @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:

    @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.

     

    It's also using base-7. 

  • Trolleybus Mechanic

    @Sutherlands said:

    @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.

     

    It's also using base-7. 
     

    Base-8. If it was base-7, 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:

    Base-8. If it was base-7, 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:

    Base-8. If it was base-7, 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)

    Well, if you take into account that what I said was a joke, following on the 23-bit wide integer, then yes, please sit the week out.  (Although I think it has been determined that it was last week.)


  • @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?

    ;-)

     


Log in to reply