RFR: 8295146: Clean up native code with newer C/C++ language features [v3]

Kim Barrett kbarrett at openjdk.org
Wed Nov 23 05:24:24 UTC 2022


On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Sorry my eyes must be playing tricks on me. ??
>> 
>> Why did you need to add this here?
>
> It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11:
> 
>> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage.
> 
> While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead:
> 
>> §11.3/4 [class.friend]
> A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1).

I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted.

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

PR: https://git.openjdk.org/jdk/pull/11081


More information about the security-dev mailing list