AutoHotkey Community

When a function in a DLL has a 64 bit integer parameter not in the last position of the parameter list, the DLL call fails with access violation. I experienced this with f(str,Int64,Int64) and f(str,Int64,str) parameter types. If the Int64 parameter is the last one, everything seems to be OK, like in f(str,Int64) or f(str,Int,Int64). All these functions are "CDecl".

I couldn't reproduce it. Perhaps the DLL function in question is expecting something other than a pure __int64 coming in. Some functions might expect a 4-byte pointer to an 8-byte structure containing the 64-bit value.

Here is the test I ran:

Define a function in a DLL file:

Call the above function from a script:

I wrote an AHK function library to interface to GMP. The DLL is downloaded from http://www.cs.nyu.edu/exact/core/gmp/, but seeing the errors I recompiled it, with the same results. The bad functions don't return a value. Here is the list of the three DllCalls causing access violation:Most of the other long integer functions work. If I replace the offending (not the last) UInt64 types with UInt, there is no more access violation. It is hard to believe that the DLL is wrong, because so many people access it from their C programs. Still, is there a way to verify the correctness of the DLL?

In the source code (gmp.h) the declaration is OK:Can it be, that "Str" for pointer parameters causing the trouble?

(Just thinking... The source code is for GCC, a number of changes are necessary for MS Visual Studio. Maybe, those replacements of "unsigned long int" with "__UINT64" broke somewhere. Can we tell from the DLL what the actual type of a function parameter is?)

I don't know how to tell the type of a parameter just by looking at a compiled DLL file. In fact, I don't know how to find out anything at all about a function's parameters unless you have the source (except through trial and error).

I would guess that the function expects 32-bit integers rather than 64-bit. If that's not it, perhaps the functions are not CDecl after all, though I'm not sure if that would explain why ErrorLevel indicates access violation.

I am confused. If there is no way to tell the type (or at least the size) of the parameters, how could AHK set ErrorLevel An? I changed all the UInt64 parameter types to UInt, which makes now the total length of the parameters 4 or 8 bytes shorter. Everything seems to work fine, but I was expecting either before or now these An ErrorLevels.

In the fineprint of the documentation, it states, "a Cdecl function never produces the An error". The reason is that the program cannot detect how many parameters a Cdecl function requires. By contrast, a non-Cdecl function reveals the total size of its parameters when it returns to its caller, which the program detects and reports via An.

So I guess for a Cdecl function, if you don't know the number or type of parameters to pass, the only clue you get from the program is whether an exception such as access violation was generated. Of course this is a poor clue compared to the An ErrorLevel.