All streams in ostream.hpp end up using `outputStream::do_vsnprintf()`, which uses `os::snprintf()`, which uses `::vsnprintf()`.
The latter can fail, returning -1, e.g. in case of an encoding error. In that case, we assert in debug.
In release builds this situation gets misdiagnosed as a buffer overflow because we cast the signedness of the result away and compare it with the output buffer length (see `outputStream::do_vsnprintf()`).
The output buffer will be zero-terminated at its end by `os::snprintf()`, but that leaves the rest of the output buffer undefined. The libc may or may not have written parts of the formatted output into it, and may or may not have zero-terminated it. We then proceed to write whatever happens to be in that buffer to the stream sink (see `outputStream::do_vsnprintf_and_write_with_automatic_buffer()` resp. `outputStream::do_vsnprintf_and_write_with_scratch_buffer()`).
The latter can fail, returning -1, e.g. in case of an encoding error. In that case, we assert in debug.
In release builds this situation gets misdiagnosed as a buffer overflow because we cast the signedness of the result away and compare it with the output buffer length (see `outputStream::do_vsnprintf()`).
The output buffer will be zero-terminated at its end by `os::snprintf()`, but that leaves the rest of the output buffer undefined. The libc may or may not have written parts of the formatted output into it, and may or may not have zero-terminated it. We then proceed to write whatever happens to be in that buffer to the stream sink (see `outputStream::do_vsnprintf_and_write_with_automatic_buffer()` resp. `outputStream::do_vsnprintf_and_write_with_scratch_buffer()`).
- links to
-
Review openjdk/jdk/11160