Implementing complex structs using clusters

[thenoob94]

Thanks to this amazing community I've almost fully wrapped a gige-cam api in labview. I was able to pass clusters as structs to function. My next question would be how to tackle more complex structs? I have the C-struct and want to model this in LV and pass it to the function. I know how to model simple structs but this one has a nested structure and makes use of a union. I tried to model it like the following but this doesn't seem to work. My program is not crashing but my .so function returns an unkown error.

 

[LogMAN]

A union is always sized to its largest member, not the sum of its members. In your case, 4 bytes. You currently provide 8 bytes of memory. Try reducing the size of the union to 4 bytes.

[dadreamer]

First, C unions are special data type that allows for multiple data types to be stored in the same location. Therefore you don't need to bundle each and every field defined in your header for that union. The union length is set by the longest field. So you should pass 4 bytes in both of your cases. It's up to the code on how to interpret that union onwards: either as uint32_t "value" or as four uint8_t fields struct.

Second, you have two pointers in your main struct (pImagePtr and pUserPtr). You should pass them as 32-bit fields in 32-bit LabVIEW or 64-bit fields in 64-bit LabVIEW. To satisfy both cases, use Conditional Disable Structure with two cases for 32- and 64-bits accordingly. Now you're passing U8 fields, that will likely lead to writing to the neighboring fields inside the shared library. The same applies to size_t parameters (read here for details).

Maybe it would even be easier to make two different structs for 32- and 64-bits in Conditional Disable Structure instead of defining each parameter separately.

 

Edited May 3, 2023 by dadreamer

[Rolf Kalbermatter]

On 5/3/2023 at 2:01 PM, dadreamer said:

First, C unions are special data type that allows for multiple data types to be stored in the same location. Therefore you don't need to bundle each and every field defined in your header for that union. The union length is set by the longest field. So you should pass 4 bytes in both of your cases. It's up to the code on how to interpret that union onwards: either as uint32_t "value" or as four uint8_t fields struct.

Second, you have two pointers in your main struct (pImagePtr and pUserPtr). You should pass them as 32-bit fields in 32-bit LabVIEW or 64-bit fields in 64-bit LabVIEW. To satisfy both cases, use Conditional Disable Structure with two cases for 32- and 64-bits accordingly. Now you're passing U8 fields, that will likely lead to writing to the neighboring fields inside the shared library. The same applies to size_t parameters (read here for details).

Maybe it would even be easier to make two different structs for 32- and 64-bits in Conditional Disable Structure instead of defining each parameter separately.

Totally correct so far but you forgot that size_t is also depending on the bitness, not just the pointers itself. So these values also either need to be a 32-bit of 64-bit integer value.

[dadreamer]

14 hours ago, Rolf Kalbermatter said:

but you forgot that size_t is also depending on the bitness, not just the pointers itself

For that I have left this sentence with a reference to your message and the next ones after:

On 5/3/2023 at 5:01 PM, dadreamer said:

The same applies to size_t parameters (read here for details).

But I would say that size_t type rather depends on a target bitness, than on a platform bitness. On 32-bit OS we can compile 32-bit applications and cross-compile 64-bit ones, if supported by the compiler. On 64-bit OS we can freely compile both. So sizeof(size_t) is either 4 bytes for 32-bit target or 8 bytes for 64-bit target. I've just checked that in MS Visual Studio.

[Rolf Kalbermatter]

Yes it of course depends on the target you are compiling for. The actual application target, not the underlying OS. It's the same for pointers and size_t datatypes (at least in any system I know of. There is of course theoretically a chance that some very obscure compiler chooses a different type system. But for the systems that are even an option for a LabVIEW program, this is all the same).

Edited May 8, 2023 by Rolf Kalbermatter