On Wed, 20 Nov 2024 00:33:31 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure >> unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length >> limit already used in part of that code. >> >> Just to clarify the issue. The size 1024 is an internal buffer limit that >> `fthrow` uses - it is an implementation detail and not something the caller >> should think about. It is also not relevant to the underlying problem, which >> is the size of the buffer needed for the fully expanded format string, which >> `os::vsnprintf` will try to calculate and report. The intent is to check >> callers can't hit that underlying `vsnprintf` INT_MAX limit. When your >> format string only deals with a few symbols and symbols are always < 64K >> then we know we are nowhere near that INT_MAX limit. If your format string >> can take a potentially arbitrary (usually from outside) string then it needs >> to put its own size guard in place using `%*s`. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains three additional > commits since the last revision: > > - Merge branch 'master' into 8339134-fthrow > - Restore previous behaviour for zero length strings > - 8339134: Callers of Exceptions::fthrow should ensure exception message > lengths avoid the INT_MAX limits of os::vsnprintf OK, LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21867#pullrequestreview-2459486538