• (nodebb)

    You need to review your markup... Currently, the second code block uses "#define BYTES_TO_WORD(lo, hi) (((uint16_t)hi << 8) + (uint16_t)lo)" as a CSS class...

  • (nodebb)

    Re lobyte first in make-word macros...

    I give you the official prototype definition of the Win32 MAKEWORD macro/function:

    WORD MAKEWORD(
   BYTE bLow,
   BYTE bHigh
);
  • Debra (unregistered)

    How do we know that BYTES_TO_WORD accepts the lower order bits as its first parameter? The result would've been zero anyway, since the result of that is ANDed with 0x0002, while the return value is ANDed with 0x0004 - that yields zero as far as I know.

  • LCrawford (unregistered)

    get_sensor_orient() was copied from the previous project which used 16 bit sensor status word and different status bit positions. Test in horizontal position: it worked! Ship it!

  • (nodebb) in reply to Debra

    How do we know that BYTES_TO_WORD accepts the lower order bits as its first parameter?

    Bad formatting of the HTML caused the definition to be used as the class name in the tag.

    It is:

    #define BYTES_TO_WORD(lo, hi) (((uint16_t)hi << 8) + (uint16_t)lo)
  • (nodebb)

    Ugh.

    #define BYTES_TO_WORD(lo, hi) (((uint16_t)hi << 8) + (uint16_t)lo)
  • Debra (unregistered) in reply to Steve_The_Cynic

    Ooooooooh. Thanks!

  • (nodebb)

    I wonder if this code is used by Apple. It would explain the behaviour of my iPad.

  • Code Refactorer (unregistered)

    Maybe the programmer made the mistake of thinking that "the second bit" is not 2^1=2, but 2^2=4. I already saw a lot of code that got it wrong in assuming the n-th bit is addressed as 2^n or 1<<n instead of 2^(n-1) or 1<<(n-1). In some lectures at my university the bits were even counted from left to right instead of right to left, imagine how confusing that was! Also in which order the bytes of a word are stored is hardware dependent: Big Endian versus Little Endian. So it depends on your experience if you guess the order in the MAKEWORD command right.

  • Blarg (unregistered)

    "We create byte called buf and pass a reference to that byte to read_sensor_reg. "

    No we don't. We pass a POINTER to buf to read_sensor_reg. That's a different thing.

  • doubtingposter (unregistered)

    So even if they had used the proper macro argument order, AND had used the proper masks to check the value on return... it STILL wouldn't have done what the explanation says because it would have returned either '0' or '2', instead of '0' and '1'.

    a wonderful triple WTF.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    This definition of BYTES_TO_WORD() also doesn't protect all of its arguments with parentheses appropriately, so if try to do something like BYTES_TO_WORD(a + b, c + d) you'll get some fun results.

    (Yes, yes, TRWTF is the C preprocessor.)

  • (nodebb)

    C'mon folks, nobody's replaced this with a tri-state "if" construction? Let's get those alternateWTF snippets going!

  • (nodebb)

    The sensor is telling the truth. It's reporting the state of the original programmer: Horizontal. As in dead. Specifically, brain dead.

  • sizer99 (google)

    Even as terrible as this is it's nice to see some real bit-banging instead of the usual bletcherous database/web stuff.

  • Chris (unregistered) in reply to sizer99

    So that should be calling a database connection factory, to create a connection to a database that stores information about every sensor, making multiple round-trip queries to fetch the data for the sensor in question...? I feel like I'm missing four or five steps. Oh, and the data for orientation can be horizontal / H / h / vertical / V / v / 0 / 1 / TRUE / FALSE / ORIENTATION_NOT_FOUND / null.

  • A Bit Old School (unregistered)

    This isn't even that bad, it's just wrong. There's a couple of dumb mistakes in there, and yes, the widening is unnecessary - I guess they have other code that expects a 16 bit integer and this is a copy/paste.

    Returning the masked value is the worst bit because that will always return 2 (or 4) instead of 1. Although like the comment said above, the macro definition is wrong if you put an expression in its arguments. (TRWTF is surely that C macros don't automatically parenthesise arguments. Is there any reasonable use case where you don't want that?)

    Having a test case would have caught the incorrect behaviour.

  • WTFGuy (unregistered)

    @A Bit Old School. Naaah, testing is for sissies. I know my code works. After all, it compiled didn't it?

  • .. (unregistered) in reply to Chris

    I think they were saying that must posts on the website aren't bit-banging stuff

  • Naomi (unregistered)

    TRWTF is surely that C macros don't automatically parenthesise arguments. Is there any reasonable use case where you don't want that?

    http://jhnet.co.uk/articles/cpp_magic

    tl;dr Reasonable? Not for normal developers, but sometimes in framework-y utility-y code - and that was way more important "back in the day".

Leave a comment on “A Maskerade”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article