On Thu, 4 Jun 2026 17:55:36 GMT, Kevin Walls <[email protected]> wrote:
> Native Attach API code e.g.
> src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c
> uses strdup before calling JNU_ThrowIOException
>
> char* msg = strdup(strerror(res));
> JNU_ThrowIOException(env, msg);
> if (msg != NULL) {
> free(msg);
> }
>
> This gets passed along and into e.g.
> java_lang_String::create_from_str(message, thread)
> which creates a new String object, into which the bytes are copied, so this
> strdup/malloc and free are unnecessary.
>
> We do this twice in this file, and in macos and aix versions. I've changed
> Linux and MacOs here. The same thing is done in AIX but I have left
> unchanged as I don't build/test it. Can update that also if I see any
> confirmation it's OK.
>
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
Thanks for the comments -
This was to me an annoying small inefficiency, maybe excessive caution. But
maybe it's best to just leave as it is.
I see that if you ask for strerror(1), then strerror(2), you get different
pointers, and ask for strerror(1) again you get the same as the first call to
strerror(1) did. i.e. strerror(...) returns a pointer to the library's error
text, e.g. "Operation not permitted", and that text exists at the same place
each time.
The idea of the returned pointer being invalidated or its contents changed on a
subsequent call to strerror() was strange to me. BUT, if the error number is
unknown, then yes you will get the same pointer each call, containing a
different string, e.g. "Unknown error 999", "Unknown error 1000". (Yes it's
unlikely connect() will invent a new errno.)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31384#issuecomment-4643833268
