On Sun, 5 Nov 2023 07:11:27 GMT, Julian Waters <jwat...@openjdk.org> wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes >> the Visual C compiler much less accepting of ill formed code, which will >> improve code quality on Windows in the future. > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Whitespace awt_Canvas.cpp > But it doesn't matter because the changes you are making aren't going in the > right direction. > The root of the compiler complaints is the gotos isn't it ? > So the code needs to be changed to not use gotos. I guess you did do that but > not in a way I'd endorse Indeed, I am planning to rewrite it in a way that doesn't use gotos (at least for the areas here where the compiler cannot compile). The reason I asked if the C++ Standard Library could be used is because std::unique_ptr can be used here to very cleanly replace the gotos, with minimal and non-disruptive code changes that would be easy to review, compared to the clunky changes I had to make here (without the C++ Library) > Do we ? I'm not sure why that is. We've previously tried hard to avoid that. > Eg https://hg.openjdk.org/jdk9/jdk9/rev/f3c96aea372d > > We should still stay away from it. So the dynamic version of the C++ Standard Library (msvcp140.dll) cannot be used. Alright. What if we statically link the C Runtime Libraries to awt.dll instead? This way, not only do we not have to worry all the time about introducing a dependency to msvcp140.dll (as everything is statically linked), but std::unique_ptr also becomes available to use here, and we also wouldn't need to do the std::bad_alloc hack that we currently do too. This is as simple as passing the -MT compiler flag to BUILD_LIBAWT in the Makefile ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1797804764
