LabVIEW
vxworks: LabView LStrHandle structure
Solved!
You must make a distinction between LabVIEW realtime and LabVIEW embedded. LabVIEW realtime shares most of the source code with normal LabVIEW and is always distributed as a binary module for the target in question, just as the LabVIEW runtime engine for desktop systems.
LabVIEW embedded is an attempt to make LabVIEW compile for other targets where NI does not have control over the hardware. In order for this to work, a lot of the LabVIEW core has to be provided in some ways in addition to source code for the translated VIs. This is a complicated process and NI has to make a balance between how much of the code they can and want make public and how much is necessary to make the whole thing work. The external code reference manual has certainly not a full meaning for the embedded source code that is distributed with the embedded module. I'm pretty sure that some of its functions are not even implemented on the embedded platform for various reasons. So you should never try to assume from the code distributed by the embedded module, how the LabVIEW runtime kernel behaves. It is likely similar but not as extensive and feature rich as the LabVIEW runtime kernel can be.
On the binary distributed runtime systems such as the desktop runtime and the realtime runtime you can assume that all functions are available and work as advertised in the Exernal Code Reference Manual because they really all share the same (proprietary and undisclosed) source code. There are a few esotoric exceptions to this depending which LabVIEW version you use.
As to your code, I can't see how that could work possibly. A LabVIEW handle is a lot more than a pointer to a pointer to a memory area. LabVIEw internally maintains a list to all its handles and verifies at various moments that a handle passed to its functions is indeed a handle in this list and will go belly up if it isn't. Even if this internal verification wouldn't be I still do not understand how your code ever could work by passing handles from and to a LabVIEW diagram from this C function.
Taking just a single line in your code, what you really should be doing there is this: (omitting NumericArrayResize in this case to make it a bit more clear how it is supposed to work).
(*(**sa)->sharr[0])->str[0]='A';
You simply replace the first character in the first array element with an A.
This makes some very bad assumptions:
1) you simply assume that this array contains at least one string handle elemen
2) you also assume that this string handle element contains at least one character
Of course you can make sure that this is the case by initializing everything on the diagram accordingly but someone at somepoint is going to get rid of that stuff, thinking it is quite superfluous or you might add one more array element or character in the C code and forget to modify the initialization in the diagram to make sure the buffers are allocated.
What you should rather do is this:
char *string = "Something";
int32 i, len = strlen(string) - 1,
numelem = 1, size = sizeof(int32) + numelem * sizeof(LStrHandle);
if (!*sa)
{
/* NULL handle, allocate a new one */
*sa = DSNewHdlClr(size);
if (!*sa) return mFullErr;
}
else if ((**sa)->cnt > numelem)
{
/* Deallocate superflous array elements */
for (i = numelem; i < (**sa)->cnt; i++)
{
if ((**sa)->sharr[i]) DSDisposeHandle((**sa)->sharr[i]);
}
(**sa)->cnt = numelem;
err = DSSetHandleSize(*sa, size);
}
else ((**sa)->cnt < numelem)
{
/* Resize handle to be large enough
err = DSSetHandleSize(*sa, size);
}
if (err) return err;
/* Fill in the string handles */
for (i = 0; i < numelem; i++)
{
if ((**sa)->sharr[i])
{
err = DSSetHandleSize((**sa)->sharr[i], len);
if (err) return err;
}
else
{
(**sa)->sharr[i] = DSNewHandle(sizeof(int32) + len);
if (!(**sa)->sharr[i]) return mFullErr;
}
MoveBlock(string, LStrBuf(*(**sa)->sharr[i]), len);
LStrLen(*(**sa)->sharr[i]) = len;
}
(**sa)->cnt = numelem;
Looks complicated? Yes! Could it be done easier? Well if LabVIEW would use a different memory layout for its variable sized data, yes probably but at the cost of much more complicated automatic management of all its variable sized data which would result in performance problems.
