RFR: 8292016: Rework JLI_ReportErrorMessageSys [v11]

Thomas Stuefe stuefe at openjdk.org
Thu Aug 18 08:56:17 UTC 2022


On Thu, 18 Aug 2022 08:23:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time 
>> 
>> Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolve issues

src/java.base/unix/native/libjli/java_md_common.c line 213:

> 211:          */
> 212:         char error[1024];
> 213:         if (strerror_r(errno, error, sizeof error) == 0) {

Please use brackets with sizeof

src/java.base/windows/native/libjli/java_md.c line 611:

> 609:  * Because Windows API errors and regular errno errors can exist at the same time,
> 610:  * compromise and error out when both are present. Windows code should ideally clear
> 611:  * the last error before a call that sets either of these!

That comment is strange. Of course Windows resets both errno or GetLastError if an API using them is called. But these mechanisms have nothing to do with each other and resetting errno if a WIN32 call is done would be wrong, and vice versa.

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

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


More information about the core-libs-dev mailing list