[Solved] determining data type to use in dllstructcreate

[MattHiggs]

Hello all.  I am attempting to create a udf for autoit which will utilize a C library in the form of a dll.  Its my first time trying something like this, so I apologize if the answer to this question seems obvious.  I am trying to define a struct used in the C library in Autoit, and I am confused as to the converted data types that I should assign to the data fields in the struct.  For example, one of the data fields is a "uint32_t" data type.  Google searching this data type reveals that this data type (I believe) is a 32bit unsigned int, but, when looking at the chart provided under the DLLStructCreate function, there are three separate table entries for types that have the data type 32bit unsigned int.  How do I pick which one should be used, not just in this case, but in general?  Thanks.

Edited April 30, 2020 by MattHiggs

[RTFC]

uint32_t is a 32-bit wide unsigned integer (range: 0 to 2^32 -1); the AutoIt equivalent is UINT. The size of a ULONG is architecture-dependent, but guaranteed to be at least 32-bit wide; likewise, DWORD is 32-bit on Win32 (CLS-compliant), but may be defined larger elsewhere (dword = 4 bytes, but a byte can (on some architectures) be defined to hold more than 8 bits).

But as long as you use any unsigned, 32-bit wide integer definition, the call stack entries won't be written and read misaligned, and should be interpreted correctly (provided you use the correct calling convention, presumably cdecl here).

Edited April 30, 2020 by RTFC

[MattHiggs]

15 hours ago, RTFC said:

uint32_t is a 32-bit wide unsigned integer (range: 0 to 2^32 -1); the AutoIt equivalent is UINT. The size of a ULONG is architecture-dependent, but guaranteed to be at least 32-bit wide; likewise, DWORD is 32-bit on Win32 (CLS-compliant), but may be defined larger elsewhere (dword = 4 bytes, but a byte can (on some architectures) be defined to hold more than 8 bits).

But as long as you use any unsigned, 32-bit wide integer definition, the call stack entries won't be written and read misaligned, and should be interpreted correctly (provided you use the correct calling convention, presumably cdecl here).

AHH.  Interesting.  Yes, you are correct.  The documentation for the C library indicates "If you need to access the DLL from non-C/C++ programming languages, note that the calling convention is cdecl."  So, basically, from what I am seeing, it doesn't really matter.  Good to know.