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

Reply via email to