06-17-2025 12:51 PM
I'm developing a C-based DLL that returns a structure containing char** members (i.e., double pointers).
typedef struct {
char **names;
char **rooms;
int count;
} Info;
This works fine in a normal C environment. However, when I try to use this DLL in LabVIEW, I run into problems. How can I properly return or pass a typedef struct containing char** to LabVIEW from a DLL?
06-17-2025 03:48 PM
What problems do you run into? LabVIEW will not create string arrays by itself from that cluster if that is what you are asking.
You can model the struct as a cluster of two u64 (or u32 for 32 bit) and an i32. Pass it to your DLL, and you get the pointers to each first char* back.
Then you copy the data using GetValueByPointer or MoveBlock.
This is a good resource about dereferencing pointers from within LabVIEW: Dereferencing Pointers from C/C++ DLLs in LabVIEW
GetValueByPointer is located here: <LabVIEW>\vi.lib\Utility\importsl\GetValueByPointer\GetValueByPointer.xnode
This will probably work:
dereferencing char**
Since you have control over the DLL, you could also create a more LabVIEW-friendly interface. Although in this case writing that interface is more work, so I won't go into detail.
06-18-2025 01:53 AM
I resolved the issue.
Refactor the code to avoid using double pointers. Instead, I used a single pointer (char*) and implemented the logic to serialize the array of strings into a single, i used different functions for getting single array (e.g., "FUNC1; FUNC2; FUNC3"). Ensure proper memory allocation and deallocation to maintain safe memory handling.
06-18-2025 03:24 AM
@Maneeha wrote:
I'm developing a C-based DLL that returns a structure containing char** members (i.e., double pointers).
typedef struct {
char **names;
char **rooms;
int count;
} Info;
This works fine in a normal C environment. However, when I try to use this DLL in LabVIEW, I run into problems. How can I properly return or pass a typedef struct containing char** to LabVIEW from a DLL?
An extra trouble is that char **names; is rather ambiguous. In C a pointer can be pretty much anything. A pointer to a pointer can be anything pointing to anything, basically anything on steroids'.
Extra trouble: memory management! Who is allocating those pointers? With what memory manager function. And who is going to deallocate it? The safest is that the memory is allocated and deallocated by the same entity, usually the caller. But that requires the caller to know how large any possible return value can be to allocate enough memory for the function to write into. Or you let the function allocate the memory and either provide an extra function export to deallocate the memory or document which memory manager function and memory manager entity was used to allocate it so that the caller can deallocate it after use. Here additional problems can be that your DLLs malloc() is operating on a completely different heap than your callers free() because of runtime library version incompatibilities. Trouble, trouble and more trouble.
Or you avoid the whole thing by changing the API to avoid such involved datatypes!!