RFR: 8305650: os::lasterror incorrectly truncates buffer in os_windows.cpp

Julian Waters jwaters at openjdk.org
Thu Apr 6 04:53:15 UTC 2023


On Wed, 5 Apr 2023 21:49:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Nevermind, just checked the POSIX version and it also has this flaw, so it's not just Windows
>
> We have a buffer `buf` of length `len` into which we need to copy a string `s` of length `n` and nul-terminate it. So the string will occupy `buf[0]` to `buf[n-1]` with the nul at `buf[n]`.
> 
> If the string + nul is too big for the buffer `n >= len` then we set `n = len - 1` so we copy a truncated `s` and then store the nul at `buf[n]`.
> 
> There is no bug here.

I don't quite follow, strlen only returns the length of the string _without_ the null terminating character, so the string's actual character data does indeed occupy buf[0] to buf[n] (since n = strlen(s)), meaning that the null terminator would be at n + 1. When strncpy is called later on it always reaches the count n before it reaches the null character, so the string that was copied is never null terminated, meaning that nulling buf[n] would actually erroneously discard the last character in the buffer

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13350#discussion_r1159279137


More information about the hotspot-runtime-dev mailing list