On Sat, 27 Dec 2025, 18:01 王靖淏, <[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?
>


Ah yes, it needs to be len - 3, or:

len -= 2;
len -= (buf[len - 1] == '.');



>
> >
> >
> > >
> > > This is my first time, and I'm not sure if I need to resubmit a
> patch.ಥ_ಥ
>

Reply via email to