How Labview stores data in memory - Win32 only

[DavidM]

Playing around with some API calls in Labview, I decided to create a few vi's explaining how Labview stores data in memory, how to get data-pointers and how to do API calls that would otherwise be impossible in LV (For example, I have written an FTP client using WinInets' FTPFindFirstFile in Labview).

For more info, refer to Application Note 154: http://zone.ni.com/devzone/conceptd.nsf/webmain/370DFC6FD19B318C86256A33006BFB78/$File/AN154.pdf

Enjoy !

David.

[Shiner]

David..

In the application note, it states "LabVIEW stores strings as 1D arrays of byte integers (8-bit characters), as shown in the following illustration. If your
handle is 0, the array is empty."

Is that true?

From my use of LV, I was under the impression that 'other' information is also included (such as string length).

If a labview string of 100 characters and contains an ascii null at position 50, it still prints out the complete string including the NULL. If I pass this string to a C function, it only 'appears' to pass the string upto the ASCII null. (This is more attributable to the C function itself, since I assume LV just passes a pointer to the memory (by ref), or a copy of the data. It is the C functions handling of the LV string that is th
e cause of the 'appear', not a fault of LV.

How does LV handle strings when they contain ASCII nulls ?
What does LV use to identify the end of a string?
Are LV strings dynamically allocated?
etc...

Just curious as to the inner workings of LV thats all.

Regards

Chris

[Greg_McKaskle2]

> In the application note, it states "LabVIEW stores strings as 1D
> arrays of byte integers (8-bit characters), as shown in the following
> illustration. If your
> handle is 0, the array is empty."
>


The key here is that this sentence is referring to a LV array of bytes.
A LV array has an int32 count followed by the data. So a LV string
has a count followed by the characters. The strings are dynamically
sized and can contain nulls. If they are to be sent to a C program,
your options are to filter the /0 characters out of the string first, or
send the LV or Pascal string. C can deal with other types of strings,
but the null terminated one is the most native. Its big disadvantage is
that it then reserves the /0 byte and doesn't deal wit
h binary string
very well.

Greg McKaskle

[DavidM]

I assume Gregs answer is sufficient, but here's my reaction anyway.
LV indeed uses a different kind of string termination: Size I32 in front of the data instead of the trailing null. So, LV actually doesn't care what chars are in the string, it just looks at the size I32. C does. And that's the reason why many API functions expect a buffer length parameter together with the buffer pointer (Example: GetWindowsDirectory). It's also best practise to fill the buffer with spaces, before you do the call.

What is confusion in AN 154 though is the handle being 0 for an empty string, as you mentioned. I GUESS they mean that the size I32 is zero... not the handle, nor the pointer. At least, that's what my code shows.

Have a nice day,
David.

[Greg_McKaskle2]

> What is confusion in AN 154 though is the handle being 0 for an empty
> string, as you mentioned. I GUESS they mean that the size I32 is
> zero... not the handle, nor the pointer. At least, that's what my code
> shows.
>


Recently, well within the last few releases, the storage of arrays and
strings was improved to be able to encode empty or zero element length
as being a NULL handle. This helps quite a bit in sparse arrays of
strings and other complex data. I believe that this is often hidden
from CINs and DLLS by inflating them before the call, but it is used
extensively throughout LV.

Greg McKaskle

[DavidM]

That might be possible. No way for me to check, since I can not figure out the handle without an API call...

By the way: are you in any way related to NI? You write that much useful info on LV on this board that I can't imagine you're not.

Thanks,
David.

[Greg_McKaskle2]

> By the way: are you in any way related to NI? You write that much
> useful info on LV on this board that I can't imagine you're not.
>


Related? By day I am a developer on the LV team. From home I often
answer a few emails. Since work has a bit of a family atmosphere, I
guess related is an OK word to use.

Greg McKaskle