<format>: Wide and multibyte versions different behavior for char arg.

[jovibor]

#include <iostream>
#include <format>

int main()
{
	char ch = -1;
	std::cout << std::format("cout: {:d}\r\n", ch);
	std::wcout << std::format(L"wcout: {:d}\r\n", ch);
}

The output:

Shouldn't the result be the same?
VS 16.11.5
Unfortunately I can't test in VS 17 at the moment.

[CaseyCarter]

This is by design, but it seems like a defect to me. Per [format.arg]/5, initializing a basic_format_arg with a char c when char_type is wchar_t results in initializing the basic_format_arg's stored value with static_cast<wchar_t>(c). On our supported platforms, char is signed and wchar_t is unsigned and has 16-bit width, so static_cast<wchar_t>(char(-1)) is in fact wchar_t{65535}. Our behavior is what the Standard specifies. I observe that the specified would be reasonable (1) if the type character in the format string were c instead of d, or (2) if char were unsigned (whether plain char is signed or unsigned is implementation-defined in C++).

I _think _ the fix is to use a different storage type that is properly value-preserving regardless of the signed-ness of char (e.g., int), which will then do the right thing whether formatted with d or c. We need to validate this suggestion, implement it, and submit an LWG issue.

[jovibor]

The wording is here, but for me this is definitely wrong, blindly convert from signed to unsigned type.
Fmt library, btw, in both cases returns same result -1.

Update:
Interestingly, at godbolt fmt returns -1 in both cases (link)
But on Windows, locally, its results coincide with std::format:

That's so C++ish...😎

[jovibor]

Is there any news on the subject, or where to track it?
Or it's gonna be another ABI-locked-C++ quirk, etched in the stone of time😌?

[frederick-vs-ja]

Why int? Is it because basic_format_arg behaves as-if it contains a variant, and the variant won't hold an unsigned char?

@vitaut, does P2909R1 intentionally make basic_format_arg hold an int when TD is char and char_type is wchar_t?

Oh, I found that it was a mistake. In P2909R2 the stored value is changed to static_cast<wchar_t>(static_cast<unsigned char>(v)), so the char value won't be handled as an int.