On Fri, Mar 15, 2019 at 12:46 PM Brian Burkhalter < brian.burkhal...@oracle.com> wrote:
> May I ask “why” if it cannot exceed 65535? > You're right, that was a bad idea ... The repetition of the overflow check bothers me. Another idea: simply move the existing utflen > 65535 into the loop. With modern processors, that should be close to free. > On Mar 15, 2019, at 12:40 PM, Martin Buchholz <marti...@google.com> wrote: > > Consider changing utflen to a long. > > On Fri, Mar 15, 2019 at 12:25 PM Brian Burkhalter < > brian.burkhal...@oracle.com> wrote: > >> For [1] please review the proposed fix [2]. It is possible to >> preemptively detect a sufficient condition for when the length of the >> modified UTF-8 encoding of the string parameter will exceed the maximum >> allowed value and thereby avert any numerical overflow in incrementing the >> accumulator which counts the number of encoded characters. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8219196 >> [2] http://cr.openjdk.java.net/~bpb/8219196/webrev.00/ > > >
