On Thu, 24 Sep 2026 07:56:22 GMT, David Holmes <[email protected]> wrote:
>>> But you need `strerror_r` for thread safety. That said we have quite a few >>> places in hotspot where we just report the numeric value so this is not an >>> essential change. >> >> Seems we still use strerror and not strerror_r quite a lot outside hotspot >> https://github.com/search?q=repo%3Aopenjdk%2Fjdk++%22+strerror%28%22&type=code >> >> Do you think this is really 'dangerous' ? I remember there were some thread >> safety issues, but not sure how 'bad' they are. >> So I better stay for now with the error code. > > Low probability of getting a secondary error whilst printing the first one. Just incidentally, I looked at strerror for something else recently - strerror generally returns a pointer to a static address of the error string (for the versions of strerror etc that I looked at), no allocation, so no real risk of concurrent/overlapping calls clashing. But if you call strerror() with an unknown error code (which is hugely unlikely), it uses a static buffer to return something like "unknown value 123". So the risk is if you have multiple overlapping strerror calls with unknown error codes, you could misreport. Yes it's very unlikely. (But this change seems fine, it's a very small set of possible error codes we could see.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32999#discussion_r4091421641
