Unexpected behavior with Coerce To Type bullet (converting integer to enum)

[DavidBoyd]

Just a followup...

I think I understand now that the LabVIEW enum wire is realized by an underlying integer index, a zero-based internal list of element names, and some elaborate guard code to ensure that the index is never outside of bounds (which was skipped by the CTT node's errant interface definition).

At edit time, the compiler checks a case structure driven by an enumeration and knows there needs to be a case assigned for each legal enum value, which may be satisfied a "default" case.

At runtime, a case structure is presented with an out-of-bounds value.  There is no "default" case specified.  What to do?

Is there any value in inspecting the code generation for the enum-selected case structure, so that if it ever encounters an out-of-bounds enum again (impossible now, but hey, work with me), it selects the case for the last enum member?  I'd argue that that is marginally safer than the present behavior (selecting the first case in the structure's BD display order).

(Just, y'know, adding a belt with those suspenders.)

Dave

[AristosQueue (NI)]

---

@DavidBoyd wrote:
Is there any value in inspecting the code generation for the enum-selected case structure, so that if it ever encounters an out-of-bounds enum again (impossible now, but hey, work with me), it selects the case for the last enum member? 

---

Is the extra checking for something that should never happen worth the performance impact of checking for it? That is the eternal question of a compiler. Remember that the code that a compiler generates is ALWAYS predicated on the compiler being perfect. For example, every modification of an array could check upstream to see if the pointer is shared by a constant that the compiler forgot to duplicate. But the compiler should always generate code to copy the constant value before passing it downstream. In LV 6.0.1, that didn't happen, which is why 6.0.2 shipped two weeks later (back in the days when that required physical media!). Would it be safer to include that pointer check? Yes. Is it the right thing to do? Pretty much never. If you design for the compiler not doing its job, you end up undermining all the work the compiler does to produce efficient code.

Despite all the bugs you've ever encountered, software still only works because it is absolutely perfect the vast majority of the time.

[AristosQueue (NI)]

> At runtime, a case structure is presented with an out-of-bounds value.  There is no "default" case specified.  What to do?

Going a bit further here... this is undefined behavior. A value out of range could hit any of the cases in the case structure. It could also execute code that isn't even part of the case structure, just start on random instructions at some later point in memory. It happens, because of the way codegen happens to be implemented at the moment, that it works out to call a frame, so the damage is minimized, but with a compiler bug, there's no guarantee of any correctness at all. Literally any behavior is legit once you step outside of the defined behavior of a datatype, and that behavior can change radically between one case structure and another even in the same version of the compiler. The MS C++ compiler had a scope limitation bug three years ago that had dynamic dispatching functions (virtual dispatching in C++) sometimes calling random levels of the hierarchy whenever a method tried to call its parent method. That took us forever to debug because so often the call looked legitimate.

Compiler bugs are both the best and the worst bugs -- worst because their impact is so devastating and it can be hard to recognize that two very different crashes are manifestations of the same issue. Best because they're generally the easiest to fix -- just apply whatever rule it is that got broken, which are generally pretty obvious.

Compiler bugs are why features that aren't officially released are called "rusty nails." Have your tetanus shots!

[DavidBoyd]

Point acknowledged.

There is some definable behavior in the presence of an out-of-bounds value.  If the behavior could be something else without a major execution penalty, that's where I'd rather be.  EDIT: Oops, missed your last "going further" post... this was a reply to your "penalty" post.  I get it that the behavior can't always be predicted.  And, was this really ever about the compiler being wrong?

I never lose my sense of wonder that software, as a human effort, is absolutely perfect nearly always.  (And when my own code, compiled with your compiler and linked to your libraries, still meets that measure, that's just transcendent.)

[JÞB]

---

@DavidBoyd wrote:

Point acknowledged.

There is some definable behavior in the presence of an out-of-bounds value.  If the behavior could be something else without a major execution penalty, that's where I'd rather be.  EDIT: Oops, missed your last "going further" post... this was a reply to your "penalty" post.  I get it that the behavior can't always be predicted.  And, was this really ever about the compiler being wrong?

I never lose my sense of wonder that software, as a human effort, is absolutely perfect nearly always.  (And when my own code, compiled with your compiler and linked to your libraries, still meets that measure, that's just transcendent.)

---

Which is exactly why you should use "Documented and Released" Features OR, Test Test Test you code thoroughly.  There are bound to be "Rusty Nails" in some of the less exposed features NI R&D plays with for specific use cases.

Those guys n gals are pretty sharp, don't get me wrong! But, if you made a Screw, would you test that it fastened just as well when the user drives it in with a hammer?  Those guys are frequently amazed at how we try to use features.  But mostly Code is always perfect until you give it to a USER