This is the mail archive of the java-prs@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]