I guess, it has to be changed. Cuz the default seems to be uptr (same as for NumGet/NumPut). it means it might be uint64/int64 for x64 AHK version.ReturnType: If the function returns a 32-bit signed integer (Int), BOOL, or nothing at all, ReturnType may be omitted. Otherwise, specify one of the argument types from the types table below. The asterisk suffix is also supported.
DllCall description Topic is solved
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
DllCall description
Re: DllCall description
How did you come to this conclusion? I think it works as expected.
Cheers
Cheers
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
Re: DllCall description
Hmm, Indeed.
I created a small mcode which just returns some 64bit number.
Code: Select all
USE64
mov rax, 0x8800000000
ret
Re: DllCall description Topic is solved
it is not expected if you read the documentation. Int is probably the most common return type, at least for windows api, so it is a very good choice for the default imo.I believe its expected to get uint64 for x64 by default.
I don't see it that way, that those functions have a counterpart to dllcall's final parameter that is.don't u think its out of line with both NumGet and NumPut counterparts?
Cheers.
Re: DllCall description
Is the problem simply that AHK retrieves UInt64 as Int64?
You can store UInt64 numbers as Int64 and use Format to display them as UInt64.
You can store UInt64 numbers as Int64 and use Format to display them as UInt64.
Code: Select all
q:: ;AHK retrieves UInt64 as Int64
VarSetCapacity(vData, 8)
NumPut(-1, &vData, 0, "UInt64")
vNum := NumGet(&vData, 0, "UInt")
vPrompt1 := vNum "`r`n" Format("{:u}", vNum) "`r`n" Format("0x{:X}", vNum)
vNum := NumGet(&vData, 0, "UInt64")
vPrompt2 := vNum "`r`n" Format("{:u}", vNum) "`r`n" Format("0x{:X}", vNum)
MsgBox(vPrompt1 "`r`n`r`n" vPrompt2)
return
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: DllCall description
No that is not the problem.
The problem is that the default return type of DllCall is a 32 bit signed integer where as it's ptr sized for NumPut/NumGet.
The problem is that the default return type of DllCall is a 32 bit signed integer where as it's ptr sized for NumPut/NumGet.
Recommends AHK Studio
Re: DllCall description
Thanks nnnik.
Default types:
DllCall: Int.
NumGet/NumPut: UPtr.
Where UPtr is: UInt (32-bit AHK), UInt64 (as Int64, 64-bit AHK).
Default types:
DllCall: Int.
NumGet/NumPut: UPtr.
Where UPtr is: UInt (32-bit AHK), UInt64 (as Int64, 64-bit AHK).
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
Re: DllCall description
I missclicked it as solved. It is not actually. Cuz the majority of scripts intended to run with AHK64 skip the return value declaration cuz it happens to function as expected in most instances. DllCall returns a pointer which is just truncated. But that's the point - its possible the system may return an address 0x80000000 or higher (especially when using VirtualAlloc() or the likes to allocate ANY 64bit virtual address) and this way we get a very dangerous lurking error. And I inspected scripts - many and many of them do have this vulnerability.
It would be preferable for DllCall to return uint64 (aka ptr) the way NumGet/NumPut do. Just for consistency.
Re: DllCall description
Most of the WinAPI return types are DWORD status values where 0 stands for OK.
Many libraries are written poorly and inconsistently with other versions of AHK - this is a neglecteable fix and will not chang the overall quality of libraries found on this forum.
Many libraries are written poorly and inconsistently with other versions of AHK - this is a neglecteable fix and will not chang the overall quality of libraries found on this forum.
Recommends AHK Studio
Re: DllCall description
Consistency has no intrinsic value.It would be preferable for DllCall to return uint64 (aka ptr) the way NumGet/NumPut do. Just for consistency.
Cheers.
Re: DllCall description
I did some frequency counts on a list of dll functions I have, and 77% of return types are Int or UInt, suggesting the default of 'Int' for DllCall is right.
I use the same abbreviations as here:
WinApi
https://hotkeyit.github.io/v2/docs/commands/WinApi.htm
Code: Select all
611 i 58.7%
211 t 20.3%
192 ui 18.4%
10 ut 1.0%
8 uh 0.8%
5 h 0.5%
2 d 0.2%
2 uc 0.2%
1041 TOTAL 100%
803 i/ui 77.1%
221 t/ut 21.2%
13 uh/h 1.2%
2 d 0.2%
2 uc 0.2%
WinApi
https://hotkeyit.github.io/v2/docs/commands/WinApi.htm
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: DllCall description
The value of consistency comes from the fact that it is not suprising to the developer.
When a pattern has been established breaking it will result in problems for the people trying to understand the larger construct.
That being said a group of 2 where both are different neither is a group nor a pattern.
Perhaps it would be best to remove the default return type so that people will be forced to define the DllCall properly.
Recommends AHK Studio
Re: DllCall description
It would be surprising if all built in functions terminated the script, it would on the other hand make all functions consistent, that is, the consistency has no value in and of itself. Hence, to make an argument for changing the default, the op needs a better argument than consistency alone.
Otherwise I agree, and removing the default is a good suggestion.
Otherwise I agree, and removing the default is a good suggestion.
Re: DllCall description
In this case AHK functions would be inconsistent with functions from all other languages - it goes against the established pattern and the established expectations.Helgef wrote: ↑04 Jan 2019, 12:50It would be surprising if all built in functions terminated the script, it would on the other hand make all functions consistent, that is, the consistency has no value in and of itself. Hence, to make an argument for changing the default, the op needs a better argument than consistency alone.
Consistency is not easily defined or found for one specific group since most things belong to multiple groups and categories.
If applied correctly it can make the language a lot easier to learn.
e.g. if we remove the default type from DllCall we should probably remove it from NumGet and NumPut too.
Recommends AHK Studio
Re: DllCall description
I over exaggerated the example of course.
I do not necessarily agree or disagree with removing default for numputget. I don't think it will happen though.
I do not necessarily agree or disagree with removing default for numputget. I don't think it will happen though.
Re: DllCall description
In my opinion, Data types are only useful in building data structures.
It doesn't make much sense for the parameter type of DllCall.
Because each parameter is aligned to A_PtrSize bytes when it is pushed into the stack.
Just consider the 64-bit input and output values in 32-bit system,
And consider that floating-point numbers should be marked correctly.
Of course, it's useful that both STR and * types of AHK have internal automation.
It doesn't make much sense for the parameter type of DllCall.
Because each parameter is aligned to A_PtrSize bytes when it is pushed into the stack.
Just consider the 64-bit input and output values in 32-bit system,
And consider that floating-point numbers should be marked correctly.
Of course, it's useful that both STR and * types of AHK have internal automation.
Re: DllCall description
Feiyue, we talk about default return value, values are returned in volatile registers, meaning, if you specify a too wide type for the return, you can get garbage return, the current problem is that you might get truncated data when you don't specify a type and the default is too small. One solution is to remove the default to force users to consider the return type, changing it to something else is only swapping one problem for another.
Cheers.
Cheers.
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
Re: DllCall description
Well, consistency is the key. Thats what makes some languages more popular than others actually. As nnnik stated, everything should be laid in easily memorizable patterns. AHK1.1 is an example of badly designed language - way too heterogeneous syntax, arguments order is messed up and so on. IMHO, there is no harm for 32 bit (DWORD) values to be returned as QWORDS for x64 AHK version by default - it wont break scripts logic.Helgef wrote: ↑04 Jan 2019, 12:50It would be surprising if all built in functions terminated the script, it would on the other hand make all functions consistent, that is, the consistency has no value in and of itself. Hence, to make an argument for changing the default, the op needs a better argument than consistency alone.
2nd popular retval is a pointer (which can be only 64bit for x64 code) nonetheless. It holds its place right after int32.
- vvhitevvizard
- Posts: 454
- Joined: 25 Nov 2018, 10:15
- Location: Russia
Re: DllCall description
U see, 32 bit values extended to 64 bit (with sign extension or zero extension) can be easily truncated:
-256 = 0xFFFFFFFFFFFFFF00, 256 = 0x0000000000000100. We just reject high DWORD w.o losing any significant digits -> 0xFFFFFF00 = -256, 0x00000100 = 256.
When a script expects 32bit int as default and gets 64bit int64, it gets the same value. But when we truncate full x64 pointer, we might corrupt it and it would lead to an exception.
So making a pointer size as default retval width (int for x86, int64 for x64) makes no harm and eliminates possible bugs. top 3 popular interpreting language Python has just integer (and float), no data width sub-type. More over, in Python, value of an integer is not restricted by the number of bits and can expand to the limit of the available memory. But that's another story.
2.
And just making the retval size descriptor mandatory would just increase code size, adding to redundancy.
btw, there is no "CDECL" for x64 code - x64 mode has only 1 calling convention so making that parameter mandatory is definitely not the best option.
Re: DllCall description
No it doesn't.When a script expects 32bit int as default and gets 64bit int64, it gets the same value. But when we truncate full x64 pointer, we might corrupt it and it would lead to an exception.
When values are returned from C functions the returning function just assigns the value to a specific register. When a 64 bit C function returns a 32 bit Integer it uses the RAX register.
When a 64 bit function returns a 64 bit Integer it assigns them to the RAX register. The thing is that these 2 are actually the same registers, except that EAX is just the lower 32 bits of RAX.
When assigning something to EAX the higher bits of RAX remain unchanged. Since DllCall now reads the value of RAX - after a 32 bit value has been returned - the higher bits will contain random data.
So no you dont get valid 32 bit results.
Recommends AHK Studio
Return to “AutoHotkey Development”
Who is online
Users browsing this forum: No registered users and 33 guests