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

[Julian Waters]

On Wed, 9 Aug 2023 06:30:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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?

I can try doing that, yes. There was actually a commit before this one that addressed the same issue in awt, but it missed this one since without -permissive- this error isn't caught, see [8241087](https://bugs.openjdk.org/browse/JDK-8241087)

Looking at the error logs, I believe this may be due to an issue this causes with templates in the comip.h header, but I don't think that's the main problem to be worried about, rather it's that malloc (and calloc and realloc and the JDK's ExceptionOccured method too by the way) is redefined like this in the first place. I don't have any ideas for how to deal with that at the moment unfortunately

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

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