Compiler is Too Smart for My Own Good

[billko]

---

@Eric1977 wrote:

I guess this is Stupid Question Time (for me at least)...why aren't you wiring that error wire to the FP.Close Invoke Node?

---

He wants it to fire regardless of error condition.  Since there is no error input, it will always fire.

[paul_cardinale]

---

@Eric1977 wrote:

I guess this is Stupid Question Time (for me at least)...why aren't you wiring that error wire to the FP.Close Invoke Node?

---

Because I want the FP to close even if there's an error.

[paul_cardinale]

---

@crossrulz wrote:

---

@billko wrote:

So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure.  So how did you fix it?  Error cluster inside the case structure going to error in on front panel close?

---

Synchronize Data Flow.vim could be used (one input being the panel reference, another being the error).

---

That should be a growable XNode.

[crossrulz]

---

@paul_cardinale wrote:

---

@crossrulz wrote:

---

@billko wrote:

So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure.  So how did you fix it?  Error cluster inside the case structure going to error in on front panel close?

---

Synchronize Data Flow.vim could be used (one input being the panel reference, another being the error).

---

That should be a growable XNode.

---

Many would agree with you.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/The-quot-Zero-Frame-Flat-Sequence-quot-aka-quot-Synch... 

[M.Lichtenheld]

A little offtopic question:

How do I know, how a Labview native Function will react, when an error is wired in?

Do they always do nothing?

[cbutcher]

---

@M.Lichtenheld wrote:

A little offtopic question:

How do I know, how a Labview native Function will react, when an error is wired in?

Do they always do nothing?

---

In general, you can open the "Help" ("Detailed Help" in the context help window, or "Help" via the right click menu) and then read the "error in" terminal description.

Here's a typical example:

error in describes error conditions that occur before this node runs. This input provides standard error in functionality.

The "standard error in" functionality means it does nothing if an error is passed.

An alternative example (taken from TCP Close Connection) states:

error in describes error conditions that occur before this node runs. With the following exception, this input provides standard error in functionality.

This node runs normally even if an error occurred before this node runs.

[Intaris]

This is clearly a bug, right?

[paul_cardinale]

---

@Intaris wrote:

This is clearly a bug, right?

---

No.  It's by design.  In general, once an error has occurred, there's no point in performing the rest of the functions; so most functions do nothing if there's an incoming error.  However functions that do things like releasing resources or closing files function even with an incoming error, because you almost certainly want those functions executed regardless of any prior error.

[Intaris]

Ooh, I disagree completely. LabVIEW has a syntax, and this behaviour violates that syntax without any visual indication of that. Therefore, the BD is lying to us.

Compiler optimisations should only offer logical shortcuts, but not anything that actually alters the final result like this. If my code is written as ABCD (using syntax defined by the language), and the order of ABCD is important, no compiler optimisation should override what I, the programmer, has actually formally defined in my code.

Really though? Am I the only one who sees this as a clear 100% black and white bug?

Are we this far gone?

[paul_cardinale]

---

@Intaris wrote:

Ooh, I disagree completely. LabVIEW has a syntax, and this behaviour violates that syntax without any visual indication of that. Therefore, the BD is lying to us.

Compiler optimisations should only offer logical shortcuts, but not anything that actually alters the final result like this. If my code is written as ABCD (using syntax defined by the language), and the order of ABCD is important, no compiler optimisation should override what I, the programmer, has actually formally defined in my code.

Really though? Am I the only one who sees this as a clear 100% black and white bug?

Are we this far gone?

---

When you wrote "This is clearly a bug", you didn't reference anything in particular, so I assumed that you were referring to the previous post (which was about error flow; and clearly that's what I was referring to).  Based on your lasted post, I'm guessing that you are referring to my original post.

Actually, it's not uncommon for compilers to rearrange things.  As for the this particular case (reference passed through a structure not enforcing execution order), I'm comfortable calling it either a "bug", or a "quirk".