Modify

Opened 10 years ago

Closed 10 years ago

#1033 closed Bug (Fixed)

UDF's missing @error checks after DLLCalls()

Reported by: Ascend4nt Owned by: Valik
Milestone: 3.3.1.2 Component: AutoIt
Version: 3.3.0.0 Severity: Blocking
Keywords: Cc:

Description

I've gone through and compiled a list of all standard include UDF's (as of version 3.3.0.0) that are missing @error checks after DLLCall's, where either the return 'array' or a passed structure is accessed after. It's a big list, so I wish you the best of luck in getting this worked out.

*ALSO another problem, many are using ANSI calls rather than Unicode (wide calls). I've marked down as much info regarding this as possible

Note: Some additional details are added for certain functions. Most are only 1 DLL Call, some are more - I commented on some, but there may be more than one DLLCall on some I didn't comment on.

[I'm attaching the file instead because the double underscored functions are being messed up by the issue tracker here]

Attachments (1)

AutoIT.UDFs.w.DLLCalls.No.Error.Checks.+ANSI.txt (9.3 KB) - added by Ascendant 10 years ago.
AutoIT UDFs with DLLCalls missing proper @error checks and/or calling ANSI variants

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by Ascendant

AutoIT UDFs with DLLCalls missing proper @error checks and/or calling ANSI variants

comment:3 follow-up: Changed 10 years ago by Jpm

I don't think we have to check something delivered by standard Windows.

I mean the .dll exists and the function is always inside,
the parameter are those described by MSDN.

So what else to check @error will never be set.

I agree we can have more usage of Unicode than ANSI functions I will check.

comment:5 Changed 10 years ago by Ascend4nt

Why are there already checks for standard DLLs then? And why was this part of the change history for v. 3.3.0.0?
"Fixed #517: WinAPI UDF - bad error checking after DllCall()"

I'm taking a guess here that there could be errors 'beyond AutoIT's control' - perhaps a bad DLL exists, or a DLL of the same name but wrong version exists in the same application's running folder. (I've actually seen that happen with psapi.dll).

I know from looking at the previous version that there were standard dll's existing for a few of the WinAPI UDF calls, and they were considered standard on the OS, so why was that ticket completed?

thanks

comment:6 in reply to: ↑ 3 Changed 10 years ago by Valik

Replying to Jpm:

I don't think we have to check something delivered by standard Windows.

I mean the .dll exists and the function is always inside,
the parameter are tose described by MSDN.

So what else to check @error will never be set.

I agree we can have more usage of Unicode than ANSI functions I will check.

All calls to DllCall() should be immediately followed by a test of @error. Period. There is no excuse for being lazy in the AutoIt libraries.

comment:7 Changed 10 years ago by Valik

  • Milestone 3.3.1.2 deleted
  • Resolution Fixed deleted
  • Status changed from closed to reopened

comment:8 Changed 10 years ago by jmichae3@…

I am trying to make kernel32.dll calls to CreateMutex() (CreateMutexA or CreateMutexU) but no matter what I do instead of getting a HANDLE back (used hwnd) I always get an emoty string for a result. should be getting 0 or NULL or a pointer value. so I tried returning a pointer, which is, after all, what a HANDLE is defined as in VC++. same result. this function works in NSIS but fails totally to work in auto-it3.

#include <GUIConstants.au3>

$kernelfunctioncalltype="" ;"A" or "W" or ""
$hmutex=0;
;-----code to prevent multiple instances. doesn't seem to work.
;-----NSIS code: System::Call 'kernel32::CreateMutexA(i 0, i 0, t "mutex-phonelistGUI-3.0-1.0") i .r1 ?e'
$hmutex = DllCall("kernel32.dll", "ptr", "CreateMutex" & $kernelfunctioncalltype, "ptr", 0x00000000, "int", 0x00000000, "str", "mutexGUI-phonelist-3.0")
$e=@error
if 0 <> $e then

msgbox(0,"error",$e) ;never pops up

endif
If 0==$hmutex OR ""==$hmutex Then

;failed to get mutex. do nothing until closing time. apparently we have succeeded

; MsgBox(0,"mutex",$hmutex)
Else

;got a mutex. another instance is running, so exit.

; MsgBox(0,"mutex",$hmutex)

Exit

EndIf

and yes, @error always is 0 no matter what kernel32.dll function I call. what's the deal with this? somebody please fix. and someone fix the variables so they can handle pointers. at least useably convert it to an int and back!

comment:9 Changed 10 years ago by anonymous

these were the rest of the calls at the end of the program. the purpose of the code was to prevent multiple instances of the program from running. however, this part of the code may not be necessary. apparently the NSIS code does not call CloseHandle for some reason, and I do not know what the upshot of this is.

while 1

Case $MSG==$GUI_EVENT_CLOSE

;$result = DllCall("kernel32.dll", "int", "ReleaseMutex" & $kernelfunctioncalltype, "ptr", $hmutex)
;if @error<>0 then
; ;do something
;endif
$result = DllCall("kernel32.dll", "int", "CloseHandle" & $kernelfunctioncalltype, "ptr", $hmutex)
if @error<>0 then

;do something

endif
Exit

comment:10 Changed 10 years ago by Valik

What the fuck does any of that have to do with this ticket? It has nothing to do with this ticket, that's what. Post on the support forum next time and read WikiStart before you attempt to use the issue tracker again.

comment:11 Changed 10 years ago by Valik

  • Severity changed from None to Blocking

Set as blocking, it needs done before the next beta.

comment:9 Changed 10 years ago by Valik

  • Milestone set to 3.3.1.2
  • Owner set to Valik
  • Resolution set to Fixed
  • Status changed from reopened to closed

Fixed in version: 3.3.1.2

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Valik.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.