Codechange: Silence clang warnings about va_start

[glx22]

Fixes passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Wvarargs]

[rubidium42]

Not sure I really like this construction.
On the other hand, the alternatives are much more invasive... although maybe consider swapping minSan and id in IssueMessage and something similar in CheckLength could help, but that means touching a lot of the code base, making this solution slightly more palatable from a review point of view.

[glx22]

After reading the comment about swapping parameters I tried something in master...glx22:grfcodec:clang-warnings-2.
It's a rename of the variadic functions with swapping of parameters, and variadic templates with the original name and order calling the new variadic functions.

[rubidium42]

... I tried something in master...glx22:grfcodec:clang-warnings-2...

I'm not fond of this approach because it's attempting to avoid the actual reorder, causing similar functions with different parameter order, which might cause further trouble later on. Though I can also imaging that it's going to cause a lot of churn given the number of IssueMessage calls.

[glx22]

Yeah I count 15 CheckLength() calls, 465 IssueMessage() calls, and 3 vIssueMessage() calls.
That's a lot of changes, and for me swapping parameters also change the implicit understanding of what the functions are doing.
Like CheckLength(int alen,int elen,RenumMessageId message,...) is easily understood as compare alen and elen then show message (which also uses the remaining parameters) if they differ.
Or for IssueMessage(int minSan,RenumMessageId id,...) the first parameter showing the importance of the message, and id and the following parameters are the actual message.

So yeah, a global reorder doesn't seem the be a good idea.

[glx22]

Now I have a third version in master...glx22:grfcodec:clang-warnings-3.
Main issue is I can't be sure it won't trigger assertions.

[rubidium42]

I guess the -2 version is the least bad solution. I do not have any other ideas that would be relatively non-intrusive to solve these warnings.

[glx22]

Hmm maybe a mix of this PR and -2, without RenumMessageId param in the XxxXxxI. So the entry point uses template (and requires RenumMessageId, then pass the args to internal (hiding the RenumMessageId for va_start) which then extract RenumMessageId param with va_args, then flow continues to vIssueMessage as before.