Call Library function seams to not have the arrays allocated

[dgholstein]

I generated a code.c and have been vexed by the int array within the structure, 

typedef struct {
	uint16_t hw_Version;
	uint16_t fw_Version;
	uint16_t dr_Version;
	uint16_t in_Version;
	uint16_t irq_Num;
	uint8_t can_Num;
	TD3Hdl str_Serial_Num;	// <--- misunderstood array, possibly the others too
	TD3Hdl str_hw_Type;
	TD5Hdl Reserved;
	} PVCI_BOARD_INFO;

When I access

(*pInfo).str_Serial_Num

I can see a non-Null value as I'd expect. But accessing the space it points to causes the DLL to fail.

BTW: Accessing the members before it works as you'd expect. Also, the GCC stuff that I attached and replicates the de-referencing indicates to me that I'm understanding a little bit the de-referencing going on here.

Can anyone help? My next step is to replicate in Linux and use GDB.

[dgholstein]

Because of the mix of shorts and chars I started to think about alignment on the call and sure as Shinola, I had a to add the MSVC switch, '/Zp1' per LabView: Using External Code in LabView:

Note When you call the LabVIEW manager functions from a DLL, use #include
extcode.h in any files that use manager functions and link to labview.lib. Set the
structure alignment of the compiler to 1 byte.

[rolfk]

---

@dgholstein wrote:

Because of the mix of shorts and chars I started to think about alignment on the call and sure as Shinola, I had a to add the MSVC switch, '/Zp1' per LabView: Using External Code in LabView:

---

That's going to bite you if  you ever happen to compile this for 64-bit. LabVIEW 32-bit for Windows does use bytepacked data structures for legacy reasons (the 32-bit version of LabVIEW was developed for Windows 95 when computer memory was still measured in Megabytes).

You seem to elude to have created C code for the VI interface, which would normally indicate that you right clicked on the Call Library Node and selected "Create C File" from the menu. If you had done that you would have ended up with a .c file with the necessary type definitions and include statements already present.

You would have seen something similar to this:

#include "extcode.h"

#include "lv_prolog.h"
typedef struct {
	int32_t len;
	uChar elm[1];
} **TD3Hdl;

typedef struct {
	int32_t len;
	something elm[1];
} **TD5Hdl;

typedef struct {
	uint16_t hw_Version;
	uint16_t fw_Version;
	uint16_t dr_Version;
	uint16_t in_Version;
	uint16_t irq_Num;
	uint8_t can_Num;
	TD3Hdl str_Serial_Num;	// <--- misunderstood array, possibly the others too
	TD3Hdl str_hw_Type;
	TD5Hdl Reserved;
} PVCI_BOARD_INFO;
#include "lv_epilog.h"

< your function prototype >

The lv_prolog.h and lv_epilog.h files make sure that the alignment is properly set and reset for the platforms where that is neccessary. As for this time only Windows 32-bit does need some custom settings anymore. All the other platforms that LabVIEW currently runs on use the compilers default structure alignment rules. which is solved by these include files by not definining any packing.

[dgholstein]

I was wondering why:

#include "lv_prolog.h"

didn't work, the documentation alluded it was taking care of alignment. Thanks for the clarification.