RFR: JDK-8296995: ostream should handle snprintf(3) errors in release builds [v3]

[Thomas Stuefe]

> 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 but don't handle it in release. There, this situation gets misdiagnosed later as a buffer overflow because we cast the signedness of the result away (see `outputStream::do_vsnprintf()`). 
> 
> ---
> 
> The patch is trivial. The most exciting thing is the gtest, I guess.
> 
> In release builds, we now treat this condition as an empty string write. I considered printing a clear marker into the stream instead, e.g. "ENCODING ERROR", but ultimately did not do it.

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  feedback martin

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11160/files
  - new: https://git.openjdk.org/jdk/pull/11160/files/0e1236e1..086a6ec3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11160&range=01-02

  Stats: 4 lines in 1 file changed: 4 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