Decompiler: Vararg parameters not always handled

Describe the bug In quite some cases the decompiler does not identify parameters to vararg functions such as printf/sprintf correct.y

To Reproduce Steps to reproduce the behavior:

1. Get a wannacry sample, for example https://www.virustotal.com/gui/file/24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c
2. Go to function FUN_00407ce0
3. Scroll down to the sprintf calls at offset 407e18
4. See that three arguments are pushed to sprintf but only two are identified.

Expected behavior The call should look like sprintf(&local_104,s_C:\%s\qeriuwjhrf_00431344,"WINDOWS")

Screenshots

Environment (please complete the following information):

• OS: macOS 10.14.3
• Java Version: 11.0
• Ghidra Version: 9.0

[nezza]

Yep, that was my workaround, but in this case the call on the assembly-side is pretty clear (and handled fine by other decompiler), that’s why I think it might be a bug

[marcushall42]

Varargs can sometimes be difficult to tell apart from local stack variables on many processors. It is possible to provide a function signature override at the calling site. This can specify the appropriate types for the various arguments on this particular call. It helps the decompiler understand what’s going on elsewhere in the function as well.