Dealing with varargs

[gynt]

I am struggling with the varargs situation of some functions. Sometimes I needed to pass on the varargs ... to a downstream function (e.g. Print functions). Therefore, I refactored ... as va_list. However, va_list is a mandatory argument.

This gives problems in functions that call vararg functions, such as is the case in ShowProgressBarSaveLoadDialog. In actuality, the below code has a jmp to MenuItemActionHandler_ProgressBarBox_LoadAndSaveGameButtonLogic. The 0 argument is moved into the first arg location on the stack, right before. So I am starting to doubt whether these MenuItemActionHandler functions are/should be varargs. If I recall correctly, they are currently varargs because a MenuItemActionHandler that is a callback for a scrollhandler receives 4 parameters, whereas most other functionality just receives a single parameter. How about we use a Union to differentiate the two callback types and clean up the MenuItemHandler declarations to not be vararg?

// FUNCTION: STRONGHOLDCRUSADER 0x00495800
void UI::ShowProgressBarSaveLoadDialog(int param_1)

{
    DAT_MenuTextInputState::instance.DAT_MenuOptionsActionParameter = (-(uint)(param_1 != 0) & 0xe) + 0x20;
    MACRO_CALL_MEMBER(OpenSHC::UI::MenuModalComposition_Func::activateModalDialog2, DAT_MenuModalComposition1::ptr)(
        OpenSHC::UI::Enums::MMT_PROGRESS_BAR_BOX);
    DAT_MenuModalComposition1::instance.activeModalDialogID = OpenSHC::UI::Enums::MMT_PROGRESS_BAR_BOX;
    MACRO_CALL(OpenSHC::UI_Func::MenuItemActionHandler_ProgressBarBox_LoadAndSaveGameButtonLogic)(0);
    return;
}

[gynt]

Coming to think of it, I actually think I made a mistake in how this all works... I will rewind the ... situation first.

[TheRedDaemon]

I forgot how these were called, but if they truly are called with a different number of parameters (different esp changes and push numbers), and they occupy the same slot in a struct, then there are only the two options you mentioned:

• The function type accepts varargs.
• The function type is a union.

It is not possible to pass on clean ... varargs in C(++). They could not have done it either (which is why varargs calls can also not be wrapped, they only work directly with the pointer).

If we are sure that there are only two types of functions, then a union might actually be the cleaner way.
Maabe even more of the opject is actually a union?

[gynt]

Yea so I think union is really the way to go, because then we also get nice callback typedefs.
From my work on the ui extension (which used C headers), this worked:

union MenuItemRenderFunctionTypeSignature {
  unsigned long address;
  void (__cdecl *simple)(int);
  void (__cdecl *gmDataImage)(int);
  void (__cdecl *slider)(int, int, int, int, bool);
  void (__cdecl *scrollbar)(int, int, int, int, bool);
};

union MenuItemActionHandlerFunctionTypeSignature {
  unsigned long address;
  void (__cdecl *simple)(int);
  void (__cdecl *slider)(int, int, int*, int*, int *);
  void (__cdecl *scrollbar)(int, int, int*, int*, int *);
};

[TheRedDaemon]

Ah, one thing though: Can you test if a struct with this union can be directly created?

In the end, we need to instantiate the structures that contains these, so it needs to work somehow to create them without any function logic.
Unless I remember wrong and the structs of these had constructors...

[gynt]

@TheRedDaemon It just gives a warning: https://decomp.me/scratch/wiLqn
No there are no constructors for these, just arrays full of MenuItem entries.
The warning disappears if I change address into an void *.

I think the invocation of the union in a function body determines the course of action, not at initialization.

[TheRedDaemon]

Alright, then everything fine from my side.