RFR: JDK-8296995: ostream should handle snprintf(3) errors in release builds [v2]
Thomas Stuefe
stuefe at openjdk.org
Mon Dec 5 08:07:25 UTC 2022
> Small fix for a very unlikely problem.
>
> All streams in ostream.hpp end up using `os::snprintf()`, which uses `::vsnprintf()`. `vsnprintf(3)`can fail and return -1.
>
> The chance for this to happen is small. snprintf errors are usually encoding errors though not always (see third example at https://stackoverflow.com/questions/65334245/what-is-an-encoding-error-for-sprintf-that-should-return-1). I found "%ls" in one place in windows coding, so I am not sure we can always exclude the possibility of wide strings being used in our code base, or that of printing with outside-provided format strings.
>
> In case of an error, we assert in debug builds. We don't handle this condition in release builds. In release builds this situation later gets misdiagnosed as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`).
>
> I think it is just safer to handle this condition, especially since the patch is super trivial.
>
> ---
>
> Patch : in release builds, we treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", and I'm open to suggestions.
Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
JDK-8296995-ostream-handle-sprintf-errors
-------------
Changes: https://git.openjdk.org/jdk/pull/11160/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=01
Stats: 33 lines in 2 files changed: 33 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/11160.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/11160/head:pull/11160
PR: https://git.openjdk.org/jdk/pull/11160
More information about the hotspot-dev
mailing list