MisMatch when UnFlattening

[Intaris]

The current solution is, IMHO, simply inferior to returning all correctly processed data until the point of error.  If we decide to throw away the Array, why not all other data also?  (And yes, I DO understand the difference between fixed- and variable-sized data in LabVIEW).  Understanding how the status quo comes about is not equivalent to defining it as the correct behaviour.  The decision to discard the array while returning other data seems like a willy-nilly decision to me - a coin-toss, whatever .  Any other way of handling it would be just as plausible.  In the absence of other aspects, I believe the behaviour should enable as many possible uses as possible without endangering the entire ecosystem.   Don't find the proposed "parse until error and then return all" as being in any way adventurous or outlandish to propose as "correct" behaviour.

PS According to the help on the unflatten function:

rest of the binary string contains any leftover bytes that this function did not convert. This function does not convert all the bytes if the size of binary string is not a multiple of the size of type.

So by design, the function is supposed to handle strings of different length than the datatype would otherwise require.  While it mentions nothing on the string being SHORTER than required, the ability to deal with WRONGLY sized strings is explicitly mentioned.  So even if it's not a bug, even if it's not contradicting the help, I personally believe it should do  as it was originally expected to do (i.e. don't throw away a perfectly well formatted array).  Return an error, but provide different errors for "Way wrong String" and "Not all elements found" in an otherwise correctly formatted string.

But I may just be in my usual minority of 1 on this .

[drjdpowell]

---

@Intaris wrote:

The current solution is, IMHO, simply inferior to returning all correctly processed data until the point of error. 

---

Isn't that what it's doing?  Going through it's algorithm to the point of first error, then skipping additional steps and returning what it's correctly processed.  The array creation must be a later step.   They should possibly throw all data away instead of returning it.

---

While it mentions nothing on the string being SHORTER than required, the ability to deal with WRONGLY sized strings is explicitly mentioned.  So even if it's not a bug, even if it's not contradicting the help, I personally believe it should do  as it was originally expected to do (i.e. don't throw away a perfectly well formatted array).  Return an error, but provide different errors for "Way wrong String" and "Not all elements found" in an otherwise correctly formatted string

---

Unflatten isn't designed to handle mal-formed or "wrongly-sized" data.   It is meant to handle a binary stream of multiple flattened items, so it expects that there may be "leftover bytes".   But not having enough bytes indicates a critical mistake, so it errors out.

PS> as a note to other reading this, if you want your saved binary data to be robust against changes in your data definition, you should consider the following options:

1) use flattened classes, as classes have a "mutation history" feature to unflatten old data.

2) Put your cluster in a Variant and flatten the Variant; Variants have type information which you can query with the Variant type library or OpenG tools.

3) Use JSON, INI, or other format where cluster elements are identified by name (so are more robust against added/subtracted elements in your cluster).

4) Add a flattened "format version" in front of the flattened cluster, and have your program maintain it's own mutation code to handle old versions.

[Intaris]

---

@drjdpowell wrote:

---

@Intaris wrote:

The current solution is, IMHO, simply inferior to returning all correctly processed data until the point of error. 

---

Isn't that what it's doing?  Going through it's algorithm to the point of first error, then skipping additional steps and returning what it's correctly processed.  The array creation must be a later step.   They should possibly throw all data away instead of returning it.

---

I have no idea what it's doing, I don't have access to the internal workings of the primitive.

I have nothing at stake here so I'm not going to bother arguing any further.  I've never used this, I don't plan to ever use this so at the end of the day I have nothing to gain from this discussion.

Doesn't change my opinion though.  Not returning the array is an unneccessary limitation of behaviour.