This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
- From: "kaloian at doganov dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 27 Jan 2007 23:14:31 -0000
- Subject: [Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
- References: <bug-30600-14003@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from kaloian at doganov dot org 2007-01-27 23:14 -------
Created an attachment (id=12971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12971&action=view)
Trivial fix -- `inlenght' is the last valid index of the buffer, so it should
be used directly, without adding it to `inpos'.
It is stated in BytesToUnicode.read(char[],int,int) java docs:
"Note the asymmetry in that the input upper bound is inbuffer[inlength-1],
while the output upper bound is outbuffer[outpos+count-1]. The justification is
that inlength is like the count field of a BufferedInputStream, while the count
parameter is like the length parameter of a read request."
But obviously, in BytesToCharsetAdaptor's code `inlength' is not used according
to the note above. Instead, it is expected `inlength' to contain a count,
which , when added to the value of `inpos', leads to the calculation of a
buffer limit greater than buffer's capacity (if `inpos' turns out to be greater
than zero).
This can be easily avoided by simply using `inlenght' in the way it is expected
to be used -- as an absolute index of array, not as a relative element count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600