[Format into string bug] wrong data when error in is true

[zigbee1]

Hello,

I reproduced a bug in format into string primitive. Apparently, the function kept a buffer of its previous value, and will output this value when error in terminal is true. It should just return default value of string which is an empty. I am using LV2015.

Thanks!

[wiebe@CARYA]

Reproduced in 2013. (Both outputs say "bug", while "" is expected for both).

Fixed in 2017.

[altenbach]

---

@zigbee1 wrote:

Apparently, the function kept a buffer of its previous value, and will output this value when error in terminal is true.

---

This is even more surprising since I would expect this function to be reentrant, so the two instance on your diagram should not even know about each other. Curiously, if you don't wire to the "formatted response",in the "1" case the "resulting string" is now blank as expected. To me it looks more like a compiler problem that is outside the formatting function.

[wiebe@CARYA]

---

@altenbach wrote:

---

To me it looks more like a compiler problem that is outside the formatting function.

---

I agree. If you replace the Format Into String in case 0 (wire a constant to the Outer Terminal), the bug is gone. BUT if you insert a Always Copy between the constant and the OT, the bug is back.

So to me, the FIS, and AC, make the compiler see the outer terminal as a reusable pointer. The second FIS doesn't write to this pointer if there is an error. If the fist case is a constant without AC, it can't do this optimization. A temporary (initialized) stub is needed and there's no bug. something like that...

[wiebe@CARYA]

In fact, a constant with AC in the first case, and a VI.Name property node in the second show the same bug if error in is true. No FIS at all! (Exciting, but shocking). One more reason to go to 2017!

[.aCe.]

wiebe@CARYA wrote:

In fact, a constant with AC in the first case, and a VI.Name property node in the second show the same bug if error in is true. No FIS at all! (Exciting, but shocking). One more reason to go to 2017!

---

It's not fixed in 2017 either!

[wiebe@CARYA]

---

@.aCe. wrote:

wiebe@CARYA wrote:

In fact, a constant with AC in the first case, and a VI.Name property node in the second show the same bug if error in is true. No FIS at all! (Exciting, but shocking). One more reason to go to 2017!

---

It's not fixed in 2017 either!

---

Ah. Silly me. It is still there in 17.0.0.

[zigbee1]

Hi, I confirmed yours above observation, but forgot to mentioned it in the original report. So it is not fixed in LV2017. I am curious on how this bug had not been raised for 5 years.

[Titen]

You successfully captured the attention of six AE's this morning. We have replicated this behavior and brought it to the attention of our R&D team. A Corrective Action Request (CAR) has been filed under #670889. They are working on this for a future release though I can't comment on a timeline. 

See the following snippet for a suggested workaround. 

[Bob_Schor]

Wow!  Imagine trying to design the set of Unit Tests to catch this (pretty obscure) bug!  My mind boggles.

Bob Schor