[External] : Problem with errno handling

[Per-Ake Minborg]

Hello David!

Thank you for your mail on errno handling.

As you say, errno is not touched in many cases, and stale values may be observed after a call, if not honoring the associated documentation. In fact, the VM itself can change the state of the thread's errno during execution.

As you rightfully point out, there are some rare cases where functions like strtol, strtoul, and strtod (libc functions) rely on resetting the errno to detect overflow/underflow via errno == ERANGE.

It seems like a good enhancement to implement this as outlined in your proposal (1):

A) Just before the call: copy the contents of the errno buffer to the thread's errno
B) Invoke the call
C) Just after the call: copy the thread's errno to the errno buffer

Down-calls that capture call state would become a bit slower. We view this as a lack of functionality and not a bug per se. Hence, I've filed a request for enhancement: https://bugs.openjdk.org/browse/JDK-8378559

Thanks again for your support!

Best, Per Minborg
Java Core Library Team

________________________________
From: panama-dev <panama-dev-retn at openjdk.org> on behalf of David Lloyd <david.lloyd at redhat.com>
Sent: Tuesday, February 24, 2026 12:25 AM
To: panama-dev at openjdk.java.net' <panama-dev at openjdk.java.net>
Subject: [External] : Problem with errno handling

I've encountered a problem with errno handling which I think is a bug. For some standard C functions, there is no way to detect whether an error has occurred, other than reading `errno` after the call is complete. However, these functions do
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCbEMWKmWRormTOV0F3vlRSWbst377z90YIWc6uBlf-Muh9juQY-52LlpyQnTaIDk0ftTvG3WFm1JrxBqrFcqjsRV6Y59hWE5m3s-trHCzcC0gQrHDwPH9t3R2azVexz$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd

I've encountered a problem with errno handling which I think is a bug.

For some standard C functions, there is no way to detect whether an
error has occurred, other than reading `errno` after the call is
complete. However, these functions do *not* set `errno` to zero on
success (and in fact are forbidden from doing so by specification).
One example which is easy to test with is `strtol`. I used this
function because it doesn't have any external side-effects, which
makes it ideal for testing.

At first I assumed it would be sufficient to initialize my call state
capture buffer to zero and read the `errno` value after the function
call (as stated in the documentation); however, this does not pre-set
`errno` itself, so if the function does not set `errno`, then the
stale `errno` value is populated back into the call state capture
buffer.

This problem manifested for me as `strtol` returning an errno value of
ENOENT on success, but only when running my test from the framework
which does some filesystem stuff before calling my test (thus leaving
this stale value in errno).

Here's a relevant quote from a recent publicly available draft C
standard (the final language is essentially unchanged):

> The value of `errno` in the initial thread is zero at program startup (the initial representation of the object designated by `errno` in other threads is indeterminate), but is never set to zero by any library function.[237]) The value of `errno` may be set to nonzero by a library function call whether or not there is an error, provided the use of `errno` is not documented in the description of the function in this document.
> [237] Thus, a program that uses `errno` for error checking would set it to zero before a library function call, then inspect it before a subsequent library function call. Of course, a library function can save the value of `errno` on entry and then set it to zero, as long as the original value is restored if `errno`’s value is still zero just before the return.

I believe that one of the following solutions could be considered:

1. Always populate `errno` from the call state buffer before the call,
if the `errno` call state is captured
2. Clear `errno` before any call which captures it
3. Create a new linker option which does one of the above (this has
the disadvantage of treating this as an enhancement rather than a fix,
leaving users of previous JDKs out in the cold)
4. As a more radical solution, reconsider adding permanent fields to
`java.lang.Thread` for this purpose to replace the captured call state
buffer, allowing more direct access to `errno` and its
Windows-specific brethren

As a workaround, you could conceivably bind the (platform-specific)
function or symbol which returns the pointer to the "real" errno and
push a zero value into the resultant memory segment. I did confirm
that this "works". However, this could potentially be disastrous in
the face of virtual threads, which could cause the OS thread to change
in the time between when the errno value is cleared and the actual
downcall is executed, or in the case where the JVM performs some work
at a safepoint that may indirectly cause `errno` to be reset.

Since this is a problem that users cannot feasibly solve on their own,
which prevents interaction with functions that use `errno` in a
standard way, I consider that this is a bug in the current `errno`
support.

Thoughts?

--
- DML • he/him


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20260224/992bb4da/attachment-0001.htm>