MisMatch when UnFlattening

[tst]

---

@Intaris wrote:

---

@tst wrote:

The bottom line is that you should not use this. Use something like the OpenG VIs.

---

I disagree. The bottom line for me is this is a bug.

---

I wouldn't classify the failure to convert invalid data as a bug. Sure, under this specific circumstance you could argue that there's a good reason for this to succeed, but I don't think it's a given and I certainly wouldn't count on it being official without proper documentation. Hence, the suggestion to use code that is actually supposed to work.

[CoastalMaineBird]

Attached is a simple VI which:

1... Has a default CLUSTER of 5 items (TypeDef 1), containing an array as item #2.

2... Flattens TypeDef 1 into a string, displayed in hex.

3... Unflattens that string, using TypeDef 1, and displays the result (correct data) and any error (no error).

4... Has another cluster (TypeDef 2) which is the same as TD 1, except it has one more boolean after all else.

5... Unflattens the same string, using TypeDef 2, and displays the result (Empty Array, correct data before and after) and any error (Error 74).

It still doesn't make sense to me why the second case shows correct data BEFORE and AFTER the array, but the array always comes up empty.

I see no way to interpret the data except

00 - boolean (false)

01  U8 #1 (1)

0000 0002  (2-element array follows)

02   U8 element 0 (2)

03   U8 element 1 (3)

04   U8 #2 (4)

01  Bool #2 - TRUE

[Intaris]

---

@tst wrote:

---

@Intaris wrote:

---

@tst wrote:

The bottom line is that you should not use this. Use something like the OpenG VIs.

---

I disagree. The bottom line for me is this is a bug.

---

I wouldn't classify the failure to convert invalid data as a bug. Sure, under this specific circumstance you could argue that there's a good reason for this to succeed, but I don't think it's a given and I certainly wouldn't count on it being official without proper documentation. Hence, the suggestion to use code that is actually supposed to work.

---

Either return ALL found elements or none.  If the string is truly unacceptable it should return all defaults OR else whatever it could decipher, not a willy nilly mixture.

[CoastalMaineBird]

 If the string is truly unacceptable it should return all defaults OR else whatever it could decipher

I suppose that the ERROR 74 means that the caller should disregard any and all outputs from the function.

So it doesn't matter what gets returned.

[tst]

---

@CoastalMaineBird wrote:

It still doesn't make sense to me why the second case shows correct data BEFORE and AFTER the array, but the array always comes up empty.

---

Again, I didn't look at your code or the documentation and I don't know what the code looks like behind the scene, but my guess is that the process goes something like this (starting from your step 4):

1. Take a stream of bytes and try to unflatten them to a cluster.
2. Start iterating over the elements of the cluster and take the relevant number of bytes for each element (this number is either fixed by type or encoded in the data for variable-length elements).
3. When you get to the array, make room for the array somewhere in RAM and fill it up. Remember the pointer.
4. When you're done, put the pointer into the correct place in the cluster so that you have the data.

My guess is that step 4 is never reached, because at some point LV reaches an element of the cluster which doesn't have corresponding data and at that point it stops and returns an error, and the cluster it built so far.

Of course, there are other ways this could work. For instance, LV could fire off threads to build the arrays and wait on replies from them. The arrays might be cleaned up explicitly to avoid memory issues. Array unpacking might be left to the end of the process because it's more expensive, or because it's simply easier to handle the flat data first, etc. I don't think it really matters exactly what the algorithm is, as this is undefined behavior.

[tst]

---

@Intaris wrote:

Either return ALL found elements or none.  If the string is truly unacceptable it should return all defaults OR else whatever it could decipher, not a willy nilly mixture.

---

A reasonable position. Still doesn't necessarily make the current behavior a bug, as it's undefined.

[CoastalMaineBird]

FWIW, LV 2015 has the same behavior.

SO, it looks like the setting up of the array is something that is held off until last (when unflattening), and if there is an error before doing that, that task is abandoned, and the array left empty.

As much as it seems to make sense to be able to read the data in this case, it doesn't seem like an actual bug.  GIven that it reports an error, it's not unreasonable to invalidate ALL other outputs.

[CoastalMaineBird]

My guess is that step 4 is never reached,

I guess that is what is happening.

If you remove the ARRAY from the TypeDefs in my example, the EXACT same thing happens.  You get ERROR 74 on the second case.

But it just so happens that all the other data is correct, so it looks like it's useful.

[Intaris]

---

@tst wrote:

---

@Intaris wrote:

Either return ALL found elements or none.  If the string is truly unacceptable it should return all defaults OR else whatever it could decipher, not a willy nilly mixture.

---

A reasonable position. Still doesn't necessarily make the current behavior a bug, as it's undefined.

---

I'll concede it's not really a bug since it DOES return an error.  But I still find the behaviour unneccessary and misleading.  Why not populate the array?  What decision led to this implementation?  I can't make sense of it at all and as we see, there's a potential application which does not work as expected as a result.

This is a basic functionality which (IMHO) should be robust as possible without limiting the experienced user from leveraging it to their advantage.  I also think there should be a different error for attempting what is going on here (String too short but otherwise perfectly formatted) to a truly corrupt string (incomprehensible values, Array size longer than the input string,  non-matching Enum values and so on).  But that's just me.  I don't like LabVIEW stopping me from doing things I know can be done.  I uderstand the risks, the limitations and have taken care to keep all my ducks in a row, but LV just doesn't believe me .

Just my 2c.

[tst]

---

@Intaris wrote:

Why not populate the array?  What decision led to this implementation?  I can't make sense of it at all and as we see, there's a potential application which does not work as expected as a result.

---

Well, I already gave some options for what the algoritm might be. Of those options, I expect the most likely is the "do the flat data first, then do the others and point to them", which presumably fails near the end of the first step, but returns the unflattened data, because it already did the work and might as well show you how far it got. I certainly understand how this can be confusing, but like I said, my expectation was that it would have returned default data, because I would not have even tried this, knowing it is doomed to fail.

I don't think the potential application does not work as expected as a result of this behavior, but as a result of a faulty premise, which assumes you can magically unflatten data saved as one format into data saved as another. Once you set the expectation correctly, there is no longer an issue, because you don't expect this to work.

You can of course argue that the unflatten primitive should be smarter or more stupid or whatever, but I see its basic goal as "flatten the data, then unflatten it back", not as "allow data to converted". If that's your goal, there are other tools.