On Sat, 27 Dec 2025, 18:59 王靖淏, <[email protected]> wrote:
> On Sun, Dec 28, 2025 at 2:00 AM 王靖淏 <[email protected]> wrote: > > > > On Sat, Dec 27, 2025 at 2:45 AM Jonathan Wakely <[email protected]> > wrote: > > > > > > On Wed, 24 Dec 2025 at 17:01, 王靖淏 <[email protected]> wrote: > > > > > > > > On Mon, Dec 22, 2025 at 4:37 AM Jonathan Wakely < > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > On Sun, 21 Dec 2025, 19:44 Wang Jinghao, < > [email protected]> wrote: > > > > >> > > > > >> Ignoring FORMAT_MESSAGE_IGNORE_INSERTS when retrieving system > > > > >> error messages from FormatMessage may result in unexpected error > messages and > > > > >> trigger new exceptions. > > > > > > > > > > > > > > > For those like me who have no idea what this is about, this > explains it: > > > > > https://devblogs.microsoft.com/oldnewthing/20071128-00/?p=24353 > > > > > > > > > > Can we add a test with error code 87? > > > > I discovered that `std::local` does not affect the language used by > > > > the system error information obtained by `FormatMessage`. It seems > > > > that `void test3()` in > > > > > `libstdc++-v3\testsuite\19_diagnostics\error_category\system_category.cc` > > > > cannot pass errors in non-English language environments. > > > > > > > > > > > > > > >> This patch changes the > > > > >> std::system_category.message(int) to be the same as the flags in > > > > >> gcc/plugin.cc:win32_error_msg() > > > > >> > > > > >> libstdc++-v3/ChangeLog: > > > > >> > > > > >> * src/c++11/system_error.cc: > > > > > > > > > > > > > > > This changelog entry is missing a description. > > > > I'am sorry I forgot. ; ( > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > > * src/c++11/system_error.cc (std::system_category): Add flag > > > > FORMAT_MESSAGE_IGNORE_INSERTS and > > > > FORMAT_MESSAGE_MAX_WIDTH_MASK to > > > > dwFlag parameter of the FormatMessage function. > > > > > > > > >> --- > > > > >> libstdc++-v3/src/c++11/system_error.cc | 4 +++- > > > > >> 1 file changed, 3 insertions(+), 1 deletion(-) > > > > >> > > > > >> diff --git a/libstdc++-v3/src/c++11/system_error.cc > b/libstdc++-v3/src/c++11/system_error.cc > > > > >> index b9a0b2c158f..ea7b5cd1226 100644 > > > > >> --- a/libstdc++-v3/src/c++11/system_error.cc > > > > >> +++ b/libstdc++-v3/src/c++11/system_error.cc > > > > >> @@ -162,7 +162,9 @@ namespace > > > > >> char* buf = nullptr; > > > > >> auto len > > > > >> = FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM > > > > >> - | FORMAT_MESSAGE_ALLOCATE_BUFFER, > > > > >> + | FORMAT_MESSAGE_ALLOCATE_BUFFER > > > > >> + | FORMAT_MESSAGE_IGNORE_INSERTS > > > > >> + | FORMAT_MESSAGE_MAX_WIDTH_MASK, > > > > >> nullptr, > > > > >> i, > > > > >> LANG_USER_DEFAULT, > > > > >> -- > > > > >> 2.52.0 > > > > >> > > > > > > > > I found that the existing `test03` function in > > > > `libstdc++-v3/src/c++11/system_error.cc`, used for testing > > > > `std::system_error_category.message(int)`, doesn't work correctly in > > > > non-English language environments. This is likely because neither > > > > `std::locale` nor `std::setlocale` affects the language of the error > > > > message obtained by `FormatMessage()`. > > > > > > We pass LANG_USER_DEFAULT to FormatMessage, but I don't think that is > > > related in any way to the C locale. > > > > > > I think the testcase could use SetThreadPreferredUILanguages to set > > > en-US as the language that will be used by FormatMessage. > > > > > > > Furthermore, in non-English > > > > environments, such as Chinese, system error messages end with > "."\r\n" > > > > instead of ".\r\n", which prevents `__builtin_memcmp(buf + len - 3, > > > > ".\r\n", 3) {in libstdc++-v3\src\c++11\system_error.cc:178}` from > > > > correctly removing the trailing "\r\n". > > > > > > Let's do this instead: > > > > > > if (len > 2 && !__builtin_memcmp(buf + len - 2, "\r\n", 2)) > [[likely]] > > > len -= 2 + (buf[len - 1] == '.'); > > ^ > > Is buf[len - 1] == '.' always false here? > > Can it be replaced in this way? > > while (len > 0 && __builtin_isspace(buf[len - 1])) > --len; > No because we want to remove the '.' if that's at the end. And if strings end with \r\n then we should just remove that, we don't need to handle arbitrary lengths of arbitrary spaces. > > > > > > > > > > > > > > > > > This is my first time, and I'm not sure if I need to resubmit a > patch.ಥ_ಥ >
