Variant_KVP to Strict Variant.vi sometimes incorrectly converts numeric arrays

[IlyaVino]

This occurs when the KVP variant type contains an array with numeric values and the numeric type does not match the corresponding default value variant type.

I've narrowed the bug down to the following case structure:
OpenVariant.lvlib:Variant_KVP to Strict Variant.vi with case structures: true -> default -> array -> true

Unfortunately, I do not understand the code well enough to come up with a fix.

I encountered this bug as part of an issue in: LabVIEW-Open-Source/Serializer#5

[francois-normandin]

@IlyaVino This is a difficult corner case with the method I use in this project for building arrays: I use a shortcut which creates an array of the same type as the detected type of the first element, assuming all elements are compatible with that type.
However, if one element is not of a compatible type, then it throws an error.

Am I assuming correctly that you have an array where the first element might be described with less bytes than one of the following elements in the array? (i.e. First element is a 32-bit integer and there is a 64-bit float down the line?)

If you have a screenshot of the content of the KVPs and the default variant type, I'll look into it.

Thanks!

[IlyaVino]

To answer your question, up to now I've been using small integers that have type of 64-bit float, but I can reproduce the problem with I16 and numeric arrays with small integer numbers. I do not think I've run a case where the first array element mismatches the type of a later array element as you described.

I've attached a test VI to better clarify the issue. The first two tests use PlainTextSerializer to demonstrate a test case for where I run into the issue. Note I've reproduced the issue with the 1.1.1 version. The remaining tests demonstrate cases where the type mismatch causes and does not cause an issue. I've included comments throughout. Let me know if it needs more clarification.

test_kvp parser numeric type mismatch.zip

As requested, I've also attached a screenshot of the KVP and default variant type that causes an issue. In the screenshot, I expect to get an array with values 1, 2, 3 but instead get values 0, 0, 0. This test is also included in the zip.

Thanks for your help!

[francois-normandin]

OK, I found the bug but I will need some time to think about it.
The problem is solved by requiring Strict-Matching (flag = True) because the I64 casts to I16, and since the first 6 bytes of I64 = 0, they cast to I16 as "0".

Workaround for you:

Set the flag to TRUE on "Strict Type matching?" input.

The result is that it will force this case to execute, which correctly works.

As opposed to this one that succeeds but with byte loss:

[francois-normandin]

[IlyaVino]

Sounds good! Thanks for the workaround.

[francois-normandin]

I`m going to close this issue. The KVP Parser needs to have the "Strict Type Matching" flag to true when the values stored in the Key-Value Pairs might not of the same type as the one it is being compared to.

Therefore, as shown in the test case below, if matching arrays of same type, we can forego setting the flag to TRUE, otherwise it should be. I have another test that shows it also works for arrays inside of a cluster.

test KVP Arrays (LV2013).zip

Referring to LabVIEW-Open-Source/Serializer#5 reported by @IlyaVino , there is no issue in DataManipulation, but there might be a need for the PlainText Serializer to always enforce type matching (flag = True) when calling the DataManipulation KVP Parser method. I will defer to the Serializer issue for continued discussion on this bug.