Why is Ghidra appending a memory address to a string that is displayed instead of a variable?

Question

This is my first time using Ghidra and debugging. My project deals with reverse engineering a Dos executable from 2007, to understand how it generates a code.

I looked for the strings I can read when launching the program through wine (debugging under linux) and found one place :

                    /* Reverses the string */
                __strrev(local_8);
                local_4 = 0;
                DISPLAY_MESSAGE(s__Code_=_%s_0040704c);

with DISPLAY_MESSAGE being :

int __cdecl DISPLAY_MESSAGE(byte *param_1)

{
  int iVar1;
  int errorCode;

  iVar1 = FUN_004019c0((undefined4 *)&DAT_004072e8);
  errorCode = FUN_00401ac0((char **)&DAT_004072e8,param_1,(undefined4 *)&stack0x00000008);
  FUN_00401a60(iVar1,(int *)&DAT_004072e8);
  return errorCode;
}

I named the function "DISPLAY_MESSAGE" because I saw the string on the screen ;-). I would like to name it printf but its signature does not match the one of printf since it takes byte * instead of char *, ... as input parameters and returns an int instead of void for the actual printf.

The string "Code = %s" (stripping the CRs and new lines) is actually located at address "0040704c", and I am very surprised not to see the variable holding the generated code value instead (that could help me rename the variables).

If I change the signature to the one of printf it yields :

DISPLAY_MESSAGE(s__Code_=_%s_0040704c,local_8)

which looks better, because local_8 could be the code, but I don't know if it is correct to change the signature like this (since then the local variable that I renamed errorCode is never used whereas it was returned before signature change).

void __cdecl DISPLAY_MESSAGE(char *param_1,...)

{
  int iVar1;
  int errorCode;

  iVar1 = FUN_004019c0((undefined4 *)&DAT_004072e8);
  FUN_00401ac0((char **)&DAT_004072e8,(byte *)param_1,(undefined4 *)&stack0x00000008);
  FUN_00401a60(iVar1,(int *)&DAT_004072e8);
  return;
}

So my questions are :

1. Why is Ghidra appending _0040704c to the string (should it help me, and how should I make use of this piece of info) ?
2. If my signature change is correct, what prevents Ghidra from finding the correct signature from its analysis ?
3. Should I think there is a problem with the function signature whenever I see undefinedX as it appears in DISPLAY_MESSAGE ?

Any help greatly appreciated!