LabVIEW stores data in memory for controls, indicators, wires, and other objects depending on the data type of the object.
LabVIEW stores Boolean data as 8-bit values. If the value is zero, the Boolean value is FALSE. Any nonzero value represents TRUE.
Byte integer numbers have an 8-bit format, signed and unsigned.
Word integer numbers have a 16-bit format, signed and unsigned.
Long integer numbers have a 32-bit format, signed and unsigned.
Quad integer numbers have a 64-bit format, signed and unsigned.
Fixed-point numbers have a 64-bit format, signed and unsigned.
Single-precision floating-point numbers have a 32-bit IEEE single-precision format.

Double-precision floating-point numbers have a 64-bit IEEE double-precision format.

In memory, the size and precision of extended-precision numbers vary depending on the platform, as described in the following sections:


Complex single-precision floating-point numbers consist of real and imaginary values in 32-bit IEEE single-precision format.

Complex double-precision floating-point numbers consist of real and imaginary values in 64-bit IEEE double-precision format.

Complex extended-precision floating-point numbers consist of real and imaginary values in IEEE extended-precision format. In memory, the size and precision of extended-precision numbers vary depending on the platform, as described in the following sections:


For floating point and complex numbers, s is the sign bit (0 for positive, 1 for negative), exp is the biased exponent (base 2), and mantissa is a number in the [0,1] range.
LabVIEW stores a time stamp as a cluster of four integers, where the first two integers (64 bits) represent the time-zone-independent number of complete seconds that have elapsed since 12:00 a.m., Friday, January 1, 1904, Universal Time. The next two integers (64 bits) represent the fractions of seconds.

LabVIEW stores arrays as handles, or pointers to pointers, that contain the size of each dimension of the array in 32-bit integers followed by the data. If the handle is 0, the array is empty. Because of alignment constraints of certain platforms, a few bytes of padding might follow the dimension size so that the first element of the data is correctly aligned. If you write DLLs or CINs, you might need to adjust the size of the handle that references the array.
The following illustration shows a 1D array of single-precision floating-point numbers. The decimal numbers to the left represent the byte offsets of locations in memory where the array begins.

The following illustration shows a 4D array of 16-bit integers.

In LabVIEW 7.0 and earlier, only 1D arrays are aligned in memory, which aids performance for array operations. In LabVIEW 7.1 and later, 1D and 2D arrays are aligned in memory. This aids in performance for linear algebra operations and operations involving the matrix data type.
LabVIEW stores strings as pointers to a structure that contains a 4-byte length value followed by a 1D array of byte integers (8-bit characters), as shown in the following illustration. If the handle, or the pointer to the structure, is NULL, LabVIEW treats the string as an empty string, which is the same as a string with length value of zero. Because LabVIEW uses the length value and not a terminating character to determine the end of the string, you can embed all characters that include the NULL character, or ASCII character 0, in the string at any point. When passing LabVIEW strings to external code that expects a C string, the embedded NULL characters cause the code to interpret the string as terminating at the first NULL character.

LabVIEW stores paths as handles, or pointers to pointers, that contain the path type and number of path components in 16-bit integers followed by the path components. The path type is 0 for an absolute path, 1 for a relative path, and 3 for a Universal Naming Convention (UNC) path. A UNC path occurs on Windows only and has \\<machine name>\<share name>\ rather than a drive letter as its first component. Any other value of path type indicates an invalid path. Each path component is a Pascal string (P-string) in which the first byte is the length, in bytes, of the P-string not including the length byte.
The following illustrations show how LabVIEW stores representative paths for each platform.

LabVIEW stores cluster elements of varying data types according to the cluster order. You can view and modify the cluster order by right-clicking the cluster border and selecting Reorder Controls In Cluster from the shortcut menu. LabVIEW stores scalar data directly in the cluster. LabVIEW stores arrays, strings, and paths indirectly. The LabVIEW cluster stores a handle that points to the location in memory where the data is stored. Because of alignment constraints of certain platforms, a few bytes of padding might follow the dimension size so that the first element of the data is correctly aligned. If you write DLLs or CINs, some platforms have special requirements about how you align and pad memory.
The following illustrations show a cluster that contains a single-precision, floating-point number, an extended-precision, floating-point number, and a handle to a 1D array of 16-bit unsigned integers, respectively.


LabVIEW stores embedded clusters directly, meaning that LabVIEW stores the data as if the data were not embedded in the subcluster. LabVIEW stores only arrays, strings, and paths indirectly.
The following illustration shows two different clusters that store data the same way.
LabVIEW stores waveforms like clusters.
LabVIEW stores refnums as signed 32-bit integers.
LabVIEW stores variants as handles to a LabVIEW internal data structure. Variant data is made up of 4 bytes.