On Sun, 7 Aug 2022 07:57:49 GMT, Thomas Stuefe <[email protected]> wrote:
>> Nothing I could find in the tests that suggest they use this message as
>> input, and none of them have failed with this patch, so I guess that's a
>> good thing? :P
>>
>> I am slightly concerned with going the route of 2 different calls for WIN32
>> and the C runtime, since `JLI_ReportErrorMessageSys` is a shared function,
>> only the implementations differ from platform to platform. I can't think of
>> any solution off the top of my head to implement such a change without
>> drastically changing either the Unix variant as well, or the declaration's
>> signature in the shared header unfortunately.
>>
>> I was initially hesitant to change the formatting of spacing between the
>> caller's message and system error, since the original intention for leaving
>> it up to the caller may have been to allow for better flexibility. Also a
>> concern was any behaviour differences that might result with the Unix
>> variant, but it seems like the 2 format their messages entirely differently
>> - While Windows appends the system error to the end of message without any
>> formatting, Unix prints it on an entirely separate line above the message
>> the caller passed it:
>>
>> JNIEXPORT void JNICALL
>> JLI_ReportErrorMessageSys(const char* fmt, ...) {
>> va_list vl;
>> char *emsg;
>>
>> /*
>> * TODO: its safer to use strerror_r but is not available on
>> * Solaris 8. Until then....
>> */
>> emsg = strerror(errno);
>> if (emsg != NULL) {
>> fprintf(stderr, "%s\n", emsg);
>> }
>>
>> va_start(vl, fmt);
>> vfprintf(stderr, fmt, vl);
>> fprintf(stderr, "\n");
>> va_end(vl);
>> }
>>
>>
>>> If you can make the fix for the CRT extra info small, I'd go for it.
>>
>> I don't quite get what you mean by that, should I revert the changes made to
>> the freeit checks?
>
>> Nothing I could find in the tests that suggest they use this message as
>> input, and none of them have failed with this patch, so I guess that's a
>> good thing? :P
>
> Oh, that is fine :) Thanks for looking. I just mentioned it since you are
> new-ish. The tests that run as part of GHAs are only a tiny subset of all
> tests though, therefore there can be tests that fail and you would not notice.
>
> About the rest, starting to pull a thread somewhere and then noticing that
> the thread gets longer and longer is a normal thing. Then its up to you to
> decide whether fixing the isolated issue is worth it or whether more code
> needs to be reworked.
>
> Cheers, Thomas
@tstuefe Do you think this should be ok now, since all reliance on
[JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) has been dropped?
-------------
PR: https://git.openjdk.org/jdk/pull/9749
