LabVIEW
inconsistent output when there is an error input to built-in functions - bug?
I'm not sure if this is a bug or just weird behavior, and maybe it's been mentioned before and I just couldn't find it in a search. When there is an error input to at least some built-in functions, the output is inconsistent and can be affected by operations that occur AFTER that function executes. In some cases the output is the value that was returned the last time the same instance ran without an error.
Run the attached snippet. The output is an array of [2,2], indicating that when the Scan from String function has an error in, it returns the value that was returned on the previous successful execution. Then, insert an increment function on the Scan from String output. Now it returns the array [3,4], indicating that the function executed successfully despite the input error. To me this suggests a problem, because downstream operations should not affect the output of upstream functions. If you wire a default value to Scan from String, you will get that value when there is an error.
I haven't tested other functions, but this appears to affect property nodes as well, based on this post.
This is most likely an optimization problem. I know such behaviour existed in the past with some functions and NI usually fixed it in some later release, but the recent changes in the LabVIEW compiler to use LLVM and various optimization improvements may have added this "feature" back in. The default value behaviour is certainly correct and consistent but the behaviour without default value feels not right to me for LabVIEW. In C I would say ok this is simply undefined behaviour and that means the produced code is entitled to even format your harddisk, since C explicitedly says all undefined behaviour is subject to choices by the implementor and is allowed to do whatever the implementor sees fit, including changing behavior between any version of the compiler.
But LabVIEW as a high level language has explicitedly so called default default data, which in this case should be used. Just having read a bit about LLVM I know they are wrestling with C undefined behaviour as well and LLVM being used a backend by several C compilers already has to deal with them. The reason that C explicitedly has many undefined behaviours is to allow various and sometimes significant optimizations, that could not be done, if the C standard would explicitedly require specific behaviour in certain cases (for instance uninitialized variables).
It's not an LLVM issue - I see the same behavior in LV2009, and if I'm not mistaken the LLVM wasn't added until LV2010.
I didn't specifically say that it's an LLVM issue, just that it may have been involved in this. It's defintely to do with some optimization in some ways. Similar things have happened in the past with LabVIEW functions, passing out data from previous executions in cases where they should have done nothing at all (and in order to be consistent with the rest of LabVIEW operation also return default default data in that case). And NI has always fixed that in a later release. Seems this one exists for quite some versions already and only has surfaced now.
Or maybe there is a compelling reason to behave like this, that escapes me. After all the Scan from String does have default inputs that one could use to specify what default data one wants to have in the case of an error. Unlike the property Nodes that seem to suffer from a similar problem.
Tommy in my opinion this is not how this function should perform to be consistent to general behaviour. The Scan from String function not executing at all because of the error in should produce default default data (aka empty string or array or 0 for skalars). That is for instance what a LabVIEW loop tunnel produces for loops that never execute. It should not produce whatever was the last value it produced and even less should it, like for the property node, produce whatever was the last value of this property on any property node anywhere in your program.
