On Sat, 10 Jan 2026 at 13:28, Wang Jinghao <[email protected]> wrote: > > > On 2026/1/10 20:50, Jonathan Wakely wrote: > > On Sat, 10 Jan 2026 at 12:24, Jonathan Wakely <[email protected]> wrote: > >> On Sat, 10 Jan 2026 at 12:17, Jonathan Wakely <[email protected]> > >> wrote: > >>> On Sat, 10 Jan 2026 at 10:45, Wang Jinghao <[email protected]> > >>> wrote: > >>>> On the mingw32 target, std::system_category().message(int) uses > >>>> FormatMessage api to format error messages. When the error message > >>>> contains > >>>> insert sequences, it is unsafe not to use the > >>>> FORMAT_MESSAGE_OGNORE_INSERTS > >>>> flag, as seen at: > >>>> https://devblogs.microsoft.com/oldnewthing/20071128-00/?p=24353 > >>>> > >>>> The output of FormatMessage ends with "\r\n" and includes a Full stop > >>>> character > >>>> used by the current thread's UI language. Now, we will remove "\r\n" and > >>>> any trailing '.' from the output in any language environment. > >>>> > >>>> In the testsuite for std::system_category().message(int), we first > >>>> switch the > >>>> thread UI language to en-US tomeet expectations in any language > >>>> environment. > >>> Thanks, the patch looks good now. > >>> > >>>> libstdc++-v3/ChangeLog: > >>>> > >>>> * src/c++11/system_error.cc (system_error_category) [_WIN32]: > >>>> Fix typo in __MINGW32__ macro name. > >>>> Adjust behavior on the mingw32 target. > >>> The two lines above relate to the error_category/system_category.cc > >>> test, not the src/c++11/system_category.cc source file, right? > > > Sorry, I made a mistake. The correction for the __MINGW32__ macro > > is in error_category/system_category.cc. > > > >>>> Use FormatMessageA function instead of FormatMessage macro. > >>>> * testsuite/19_diagnostics/error_category/system_category.cc: > >>>> Adjust behavior on the mingw32 target. > >>> I've just noticed that there's no Signed-off-by trailer in the patch. > >>> Do you have a copyright assignment filed with the FSF? > >>> > >>> As documented at https://gcc.gnu.org/contribute.html#legal we need > >>> either a copyright assignment, or DCO sign-off. > >>> > >>> If you don't have a copyrigh assignment, could you please add the > >>> Signed-off-by trailer if you are willing and able to agree to the > >>> terms of https://gcc.gnu.org/dco.html ? > >> Actually, don't worry, I don't think this change can be considered > >> "legally significant", because the changes are small except for some > >> whitespace changes and typo fixes. > >> > >> So I'll push this to the git repo - thanks for fixing it! > > > Thank you for your reminder! > > > > Hmm, when I test this with mingw-w64 under Wine, I get: > > > > /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/19_diagnostics/error_category/system_category.cc > > 01ec:fixme:nls:RtlSetThreadPreferredUILanguages 8, 00000001400A8122, > > 000000000021FE8C > > /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/19_diagnostics/error_category/system_category.cc:127: > > void test03(): Assertion 'msg == "Access is denied"' > > failed. > > FAIL: > > /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/19_diagnostics/error_category/system_category.cc > > > > Inspecting the 'msg' string, the content is "Access denied", which is > > what we have on trunk today. > > > > Can you confirm whether it should be "Access is denied" (as in your > > patch) or "Access denied"? > > I apologize that I haven't tested it on Wine, but the the error message > I encountered on my Windows 11 Version 10.0.26200 system was "Access is > denied," which is the same as the one recorded in Microsoft Docs, see > here: > https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Debug/system-error-codes--0-499-.md > or > https://winprotocoldoc.z19.web.core.windows.net/MS-ERREF/%5bMS-ERREF%5d.pdf > This is probably because Wine is implemented differently than Microsoft > Windows. :(
Thanks for checking. Somebody else has also confirmed that the strings are different for Windows and Wine. > > Perhaps we also need to add checks for the Wine environment, like those > found at > https://web.archive.org/web/20131028024505/https://www.winehq.org/pipermail/wine-devel/2008-September/069387.html Hmm, we could do. I think it's easier to just check that the string starts with "Access " and ends with " denied", which will match both strings. I'll change that.
