[V2.0.11:] Int is the same with Int64 in DllCall()?

[V2User]

[Moderator's note: Topic moved from Bug Reports.]

[Code1:]

Code: Select all

f(ag){
	OutputDebug(ag)
}
DllCall(CallbackCreate(f),'int64',0x0FFFFFFFFFFFFFFF)

In code1, it will output 1152921504606846975 as expected.
[Code2:]

Code: Select all

f(ag){
	OutputDebug(ag)
}
DllCall(CallbackCreate(f),'int',0x0FFFFFFFFFFFFFFF)

In code2, it should have output 0xFFFFFFFF, because the high-order part of the number has been truncated due to Integer overflowing. However, it will still output 1152921504606846975. Changing to 'int' has no effect, behaving like 'int64'.
Is there any difference between 'int' and 'int64' in DllCall()? Is this by design?

[mcl]

Is there any difference between 'int' and 'int64' in DllCall()? Is this by design?

It seems that behavior comes from CallbackCreate, not from DllCall. Quote from docs:

AutoHotkey 64-bit: All incoming parameters are signed 64-bit integers. AutoHotkey does not natively support unsigned 64-bit integers. Smaller types are padded out to 64 bits, while larger types are always passed by address.

UPD: Disregard that, I've missed the point.

[just me]

UPD: Disregard that, I've missed the point.

I don't think so.

The first four parameters are passed in 64-bit registers on x64. AHK's variables of type integer are 64-bit unsigned integer. So the whole contents will be passed. The receiver function has to strip the unused upper bits if it expects a 8-bit, 16-bit, or 32.bit value. The datatype in DllCall ist just a hint which size the called function should expect per definition.

In case of callback functions parameters are defined as 32-bit on x86 and 64-bit on x64. So parameter types in DllCalls depend on bitness:

Code: Select all

; x64
DllCall(CallbackCreate(f), 'Int64', 0x0FFFFFFFFFFFFFFF)

Code: Select all

; x86
DllCall(CallbackCreate(f), 'Int', 0x0FFFFFFFFFFFFFFF)

[lexikos]

To be clear, the native 64-bit calling convention doesn't make any guarantees about what the upper bits of the register will contain when the parameter is 32-bit, so:

• The callback should probably always truncate the parameter explicitly if it is expecting a 32-bit value, regardless of whether it is called by DllCall or external code.
• DllCall (or any call produced by a traditional compiler) is free to not truncate the input value, which allows the code to be slightly smaller and faster, regardless of whether the function being called is a callback.

AHK's variables of type integer are 64-bit unsigned integer.

Signed, not unsigned.

The first four parameters are passed in 64-bit registers on x64.

IIRC, parameters on the stack are always aligned to 64-bit boundaries on x64, so I think parameters after the fourth will behave the same way.