• (nodebb)

    So the WTF is the presentation, which omits the context and the code hidden by the ... that might contain a break; or similar.

    I'm not really in favour of doing stringly-typed matching on the device type, mind you. (Yeah, I know, a stringly-typed type.)

  • NotAThingThatHappens (unregistered)

    If the intend was to 'Do something to only one device', then the method should be split in two.

    FindSpecificDevice(); DoSomethingToDevice(device);

    If the intention is to do something to multiple devices, then variations of both methods can be made that work on collections/lists or whatever array (-ish) type. I think this is the 'S' in Solid.

  • witchdoctor (unregistered)

    Declaring variables inside a loop body has been allowed since C89. If there's a reason to have the flag visible on the outside then acting the same way if there's 1 or 100 specific_devices kind of smells too.

  • Prime Mover (unregistered)

    Nobody interested in the barfism that is 

    CC_VL_TRUE
    ?

    It's tested for being implicitly equal to "true" at the end of the snippet anyway.

    Is there ever a case for reinvention of the boolean?

    File under 

    NOT_FOUND
    .

  • Daniele (unregistered)

    Side note about the mandatory 'else' after an 'if' or chain of 'if's: when funtional safety requirements and certifications are needed, certification authority wants to be sure that your software/firmware can avoid Murphy's law, so you have to manage every single case or justify why you didn't. We are not talking about smartwatches or fancy gizmos that can be updated any time, we are talking about car or planes components or industrial measurement devices, which failures can kill people. Very restrictive specifications need you to test not only the code, but also ALL THE BRANCHES in the final assembly. Some builders also tests compilers to check the produced assembly in order to define specific coding rules.

  • Brian (unregistered) in reply to Prime Mover

    Well, this is said to be C code, and unless they've added something since the last time I used that language, C doesn't have a native boolean type. So it's practically a standard to #define your own boolean values, although most go with a plain old TRUE and FALSE without the extra decoration.

  • Simon (unregistered)

    I’d’ve processed the specific device then-and-there rather than doing it after the loop. What if >1 device was a specific device?

  • (nodebb) in reply to Brian

    C99 has a native boolean type, _Stdbool, that behaves more or less exactly like a C++ bool, but if this is C89/C90, there is, indeed, no such type.

  • (nodebb) in reply to Steve_The_Cynic

    Not all compilers implement C99. In particular, this includes some versions of compilers that are still in use out there in the wild for their ability to make truly static binaries on Windows. Newer versions might support more of C99, but they produce binaries that aren't self-contained.

    I wish I didn't know this.

  • (nodebb)

    Without seeing the entire code it is impossible to determine if the assumptions are true. There are many elements of UB that are possible. Perhaps the way the code is built, the memory location being used by the variable in question is in fact being zeroed out [local variables with non-overlapping scopes may use the same memory location. Or any of a dozen (that I can think of) considerations.

  • MaxiTB (unregistered)

    I dun get it. An else branch is in this use case useless - if it's an iteration then the variable has to be initalized outside of the loop with false. Also, not sure why the iteration doesn't terminate after the first device is found and than the flag is tested. Really hard to tell what is going on without any indication of what was implemented in the parent scope of the iteration or what happens in the condition when the flag is true ... everything is empty. Does it break out of the for statement?

  • (nodebb) in reply to dkf

    Not all compilers implement C99.

    I'm well aware of that(1). Visual C++'s own C compiler was (is?) tardy in this respect, notoriously so, and if the submitter's compiler is like that, well...

    (1) That's why I included the caveat based on "but if this is C89/C90"...

  • Yikes (unregistered)

    TOWTF is mixing the terminology "Specific Device" (which I read as "serial number") with "Device Type," which sounds like it could be the same across multiple devices.

  • (nodebb)

    Ok, confession time: I make this mistake surprisingly often. My only saving grace is that I catch it every time during mandatory testing.

  • (nodebb) in reply to MaxiTB

    You don't get it indeed.

    It iterates across all devices. All devices belonging to a specific group set the flag, which triggers some additional actions during an iteration. Devices not in this group are supposed not to trigger said actions, by not setting the flag. It's not an "iterate until you find something, then break" loop, it's an "find all of group A inside of a bigger group B loop, then do something to them". Initializing the flag outside the loop will get you the same problem, just from a different angle. (actually, you can do it inside the loop instead of making an else, depending on situation, but that's a different can of worms) Also, everything else is blank because it's irrelevant.

  • Wizofaus (unregistered) in reply to Brian

    Stdbool.h (C99) defines bool, true and false.

  • I'm not a robot (unregistered) in reply to Andre Alexin
    everything else is blank because it's irrelevant
    No. If the "WTF" is that some important piece is missing, then you can't just post some random subset of the code, because it's impossible to tell if the critical part is actually missing or just not included in the snippet. I'm still not 100% sure what the problem supposedly is - I *think* it's that the flag isn't being reset to false between iterations, but only based on reading other people's comments and assuming that they're guessing correctly. TRWTF here is definitely the article.
  • MaxiTB (unregistered) in reply to Andre Alexin

    What you are describing is a simple:

    while(ptr != NULL) { int result = getdevice(&ptr); if(result==OK && ptr->group) { /* Do stuff for group matched device */ } }

    So yes, there is no else condition or flag needed again however this expected was impossible to guess from the article because it only addresses the actual implementation. My assumption was without additional insider knowledge is perfectly valid because the use of a flag makes pretty much only sense in a targeted scenario and a general grouping ;-)

  • MaxiTB (unregistered)

    I must be getting old that I cannot write one correct sentence in a small input text box anymore - or maybe I cant blind type on cells %-)

    One more time:

    So yes, there is no else condition or flag needed again, however this expected behavior was impossible to guess from the article because it only addresses the actual implementation. My assumption was (without additional insider knowledge) perfectly valid, cause the use of a flag makes pretty much only sense in a targeted scenario additonal to a general grouping ;-)

  • Nick (unregistered)

    I can see a justification for this pattern if the “Specific Device” is a hardware dongle used for licensing…

    If the specific device is found, then we enable the software, and allow the system to do all kinds of fun things with the other devices we find.

    Unfortunately, this only works properly if the specific device is the FIRST item found - otherwise, devices A & B don’t get handled, device C is our dongle, and only devices D & E get properly handled.

    True story - an engineer I work with once drove around 300 miles to install a hardware dongle in a server to enable the “licensed” features. On arrival, he discovered that this particular server had no USB ports, so said dongle could not be connected.

  • (nodebb) in reply to Simon

    I’d’ve processed the specific device then-and-there rather than doing it after the loop. What if >1 device was a specific device?

    You're missing the entire point of the article. The processing for the specific device is done inside the loop, which only ends at the very end of the code sample. The problem is that once you find a specific device, every subsequent device is also being treated as a specific device, whether it is or not, because after the specific device is processed and the loop goes on to the next device, it never sets the flag back to false.

  • Yikes (unregistered) in reply to Nick

    PCI/ISA adapter to the rescue

  • (nodebb) in reply to MaxiTB

    And you've missed the entire point again. Look here: https://thedailywtf.com/articles/comments/the-device-search#comment-570035

  • farhankanju (unregistered)
    Comment held for moderation.

Leave a comment on “The Device Search”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article