LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

While loop oddity... is it a bug?

Hey folks,

I was trying to make a bit of code in 7.1, win2k do the following:

If an index is contained in a row of a 2D array of integers, output all of the integers for that row, otherwise, just output that index.

My somewhat convoluted VI to do so is attached.

Now, am I overthinking this (which I've been known to do :P), or is it actually taking a modification of the row downstream and modifying the input array?

I checked this on an 8.20 eval, win xp machine with the same results.

Thanks,

Joe Z.
Message 1 of 10
(4,402 Views)
Simplified example

Edit: To me, it looks for all the world like it's re-using the buffer for the For loop input when it operates on the wire downstream, rather than branching a copy off like I would expect.

Message Edited by Underflow on 08-13-2006 01:26 PM

0 Kudos
Message 2 of 10
(4,395 Views)
String version

Edit: add defaults

Message Edited by Underflow on 08-13-2006 01:45 PM

Message Edited by Underflow on 08-13-2006 01:46 PM

Message 3 of 10
(4,391 Views)
I agree this looks like a bug. Very strange.....
 
 
0 Kudos
Message 4 of 10
(4,376 Views)

For what it's worth, it's looks like a compiler-optimization gone wrong.

The example below adds a branch prior to the +1.  They see the branch and don't assume it's safe to re-use the temporary 1D.

Without the branch, "they" figured it wasn't necessary to create a copy to hold the +1 results  - since the indexed 1D array wasn't used for anything else, so they just incremented the values in place.  But the 1D being operated on (passed by reference) was a reference into the original 2D array, so they ended-up modifying the original data.

When the while-loop code peels-off a 1D array, its passing a reference to the actual data, and the +1 assumes this is a copy that's OK modify.

Fortunately For loops don't do the same thing!  

It's really good to know this is here - nice catch Underflow!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 5 of 10
(4,348 Views)
Thanks for the confirmation all.  I called NI, said they'd take a look at it.

I find myself oddly tempted to abuse the behavior as a form of pointers though.. Smiley Very Happy

Joe Z.
0 Kudos
Message 6 of 10
(4,302 Views)

Hello Joe,

Thanks for reporting this -- I hope that it doesn’t cause you too many problems.  When you hear back from the AE, please post the CAR number that (s)he gives you if you can. 

Also, I know you were probably joking, but be very cautious when exploiting a bug!  What happens to your code when the bug gets fixed?

Thanks again for posting,

Travis M
LabVIEW R&D
National Instruments
Message 7 of 10
(4,256 Views)
Hey Travis,

The AE (name forgotten already!) said that, since it was posted on the web first, the web team would handle it, but he would make sure it got forwarded to them.  No mention of a CAR yet.

Of course I wouldn't put this in production code, but tinkering is always fun.

JZ
0 Kudos
Message 8 of 10
(4,249 Views)

Hi Underflow (and others),

I'm not an AE that you spoke with, but I went ahead and filed a bug report.  This has been reported to R&D (# 40DAF67U) for further investigation. It looks like there are a couple workarounds already posted. Thanks for the feedback!

Travis H.
LabVIEW R&D
National Instruments
Message 9 of 10
(4,230 Views)
Fixed in 8.2.1.

http://zone.ni.com/devzone/cda/tut/p/id/5674

Bug# 40DAF67U

Thanks R&D 🙂


0 Kudos
Message 10 of 10
(3,692 Views)