LabVIEW
crash by invalid pointer
Solved!
This is a setting also commonly called alignment. Basically there are two different ways to define the structure alignment of structure elements.
First you have the global settings of the C compiler. Here you select what the C compiler should use if nothing else is specified in the source code. In Visual Studio it can depend on the version you are using but generally it is in the project settings under C/C++/Code Generation/Struct Member Alignment or something similar. This is default set to "Default" (sigh) which for Visual Studio is 8 byte.
Then you have the #pragma pack() compiler directive which can be used to change the alignment (temporarly) to a different explicit value. Under Windows 32-bit (and Pharlap) LabVIEW uses 1 byte alignment, under all other current platforms it uses the default alignment which for Windows 64-bit is hence 8-byte as LabVIEW is compiled with Visual Studio. Please note that other compilers might use a different default alignment. Anything that can be configured with #pragma's is generaly compiler specific, even the syntax is often totally different.
The Access Violation exception is a VERY generic exception. The CPU generates this whenever an instruction tries to access memory addresses that are not mapped into the current process. The reason for such an error are manifold and bad alignment of memory elements in structs is just one of many possible reasons for such an error.
Other possible errors are outright bugs in the DLL itself (or in LabVIEW but that is fairly unlikely), misconfigurations of the Call Library Nodes in respect to what the DLL interface really should need, and the most common one, data buffers that the DLL tries to write into but that the caller hasn't allocated (long enough). This last one is something LabVIEW can't do for you automatically as it has no way of knowing that a particular parameter is meant to be a memory buffer with a certain minimum size, and even less what that size should be. It could of course assume that any such buffer might need 1GB of memory, just to be almost always safe (well even 1GB could be not enough in certain situations) and everybody then starts to scream havoc why LabVIEW is so crazy inefficient with memory whenever you throw in that VI that contains a Call Library Node which takes such a parameter, so it's clearly not an option!
The person who programs the VI with the Call Library Node has to do that explicitly just as any C programmer has to do who tries to call that API!
