RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

Thomas Stuefe stuefe at openjdk.org
Wed Aug 9 06:32:35 UTC 2023


On Wed, 9 Aug 2023 04:00:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 2888:
>> 
>>> 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) {
>>> 2887:   if (!InterceptOSException) {
>>> 2888:     DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode;
>> 
>> I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout.
>> 
>> What is the problem, the goto? is the compiler complaining? If so, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse).
>
> Hi Thomas, the goto jumps over a lot of variable initializations, which permissive- doesn't particularly like (the failing compilation can actually be seen in the earlier GHA logs)

Ah, okay. Thanks for clarifying.

>> src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48:
>> 
>>> 46: 
>>> 47: #include "jlong.h"
>>> 48: #include "awt.h"
>> 
>> Why the reordering of includes?
>
> This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes

Oh. That's not good. Having such an undocumented reliance on order of include just begs to bitrot at some point. Any chance you could unravel that mystery, maybe in a later RFE? For now, can you please add a comment at those places where you changed include order for that reason?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288007914
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288009545



More information about the security-dev mailing list