> 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21867/files - new: https://git.openjdk.org/jdk/pull/21867/files/f0e285da..acff14ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=01-02 Stats: 316694 lines in 4333 files changed: 167153 ins; 118341 del; 31200 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867
