AHK's int32 data type should not use bits 32..63 and lower bits 0..31 contain a valid 32 bit result.
DllCall description Topic is solved
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
Re: DllCall description
I'm not quite sure what you mean here.vvhitevvizard wrote: ↑13 Jan 2019, 03:24AHK's int32 data type should not use bits 32..63 and lower bits 0..31 contain a valid 32 bit result.
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?
Recommends AHK Studio
Re: DllCall description
@ vvhitevvizard
Ahk variables uses only two number types, int64 and double, it's the same on all builds.
Ahk variables uses only two number types, int64 and double, it's the same on all builds.
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
Re: DllCall description
Alright, the matter relates only to the NumGet/NumPut/DllCall operands. Thx for the correction!
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.
Re: DllCall description
Thats an assumption - it might or might not be hard to spot. Just like the inverse might or might not be hard to spot.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 relying on undocumented features and continuing the current bad practice of incorrectly defining the return type.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.
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.Anyways, I would just love the three NumGet/NumPut/DllCall to have a unified default retval. Easy to memorize.
That would fix the underlying problems instead of making it easier for one group of people.
Recommends AHK Studio
Return to “AutoHotkey Development”
Who is online
Users browsing this forum: No registered users and 30 guests