DllCall description Topic is solved

[vvhitevvizard]

So no you dont get valid 32 bit results.

AHK's int32 data type should not use bits 32..63 and lower bits 0..31 contain a valid 32 bit result.

[nnnik]

AHK's int32 data type should not use bits 32..63 and lower bits 0..31 contain a valid 32 bit result.

I'm not quite sure what you mean here.
You said that using Ptr instead of Int would be fine on 64 bit, since the 32 bit values will be fine. But no they won't be fine.
So I don't understand this remark here as AHKs own 32 bit capabilities are never used inside the DLLCall scenario we just played through.

Or are you finally agreeing that the default return type should be Int?

[Helgef]

@ vvhitevvizard
Ahk variables uses only two number types, int64 and double, it's the same on all builds.

[vvhitevvizard]

Ahk variables uses only two number types, int64 and double, it's the same on all builds.

Alright, the matter relates only to the NumGet/NumPut/DllCall operands. Thx for the correction!

Or are you finally agreeing that the default return type should be Int?

At the moment, scripts that use DllCall w/o retval declaration and expect ptr will fail on rare occasions due to ptr being truncated with AHK64.

Now let's imagine, the default retval size is changed from int (int32) to int64, scripts that run with AHK64 and expect int (int32) will either fail instantly in most cases (easy to pinpoint) if the callee doesn't clean up the upper DWORD or will work w/o issues if the callee does clean up full rax before returning eax.

And I've seen quite a few system DLL functions that do xor rax, rax (clean up the whole rax) just before the final retval assignment even if they r expected to return just eax or even ax, al.

Anyways, I would just love the three NumGet/NumPut/DllCall to have a unified default retval. Easy to memorize.

[nnnik]

Now let's imagine, the default retval size is changed from int (int32) to int64, scripts that run with AHK64 and expect int (int32) will either fail instantly in most cases (easy to pinpoint) if the callee doesn't clean up the upper DWORD or will work w/o issues if the callee does clean up full rax before returning eax.

Thats an assumption - it might or might not be hard to spot. Just like the inverse might or might not be hard to spot.

And I've seen quite a few system DLL functions that do xor rax, rax (clean up the whole rax) just before the final retval assignment even if they r expected to return just eax or even ax, al.

Thats relying on undocumented features and continuing the current bad practice of incorrectly defining the return type.

Anyways, I would just love the three NumGet/NumPut/DllCall to have a unified default retval. Easy to memorize.

I think the best option here is to force the users to define a data type in all three cases and remove a default type.
That would fix the underlying problems instead of making it easier for one group of people.