Re: Bug in natString.cc / command line args wrong

[Martin Kahlert <martin dot kahlert at infineon dot com>]

Hello Tom,

On Thu, Sep 19, 2002 at 07:45:58PM -0600, tromey@redhat.com wrote:
> >>>>> "Martin" == Martin Kahlert <martin.kahlert@infineon.com> writes:
> 
> Martin> Here is a bug i found with the help of a Solaris 2.8 iconv bug.
> Martin> Here is a patch:
> 
> Martin> --- natString.cc.old	Thu Sep 19 11:20:47 2002
> Martin> +++ natString.cc	Thu Sep 19 11:21:44 2002
> Martin> @@ -506,7 +506,7 @@
> converter-> setInput(bytes, offset, offset+count);
> Martin>    while (converter->inpos < converter->inlength)
> Martin>      {
> Martin> -      int done = converter->read(array, outpos, avail);
> Martin> +      int done = converter->read(array, outpos, count);
> Martin>        if (done == 0)
> Martin>  	{
> Martin>  	  jint new_size = 2 * (outpos + avail);
> Martin> @@ -520,6 +520,7 @@
> Martin>  	{
> Martin>  	  outpos += done;
> Martin>  	  avail -= done;
> Martin> +         count -= done;
> Martin>  	}
> Martin>      }
> Martin>    converter-> done ();
> 
> Martin> converter->read takes the number of chars to convert, not the
> Martin> number of bytes available in the output buffer!
> 
> I'm afraid I don't understand.
> 
> My understanding is that the 3rd argument to converter->read is the
> number of characters we can convert -- that is, the number of free
> slots in the output buffer.

Yes - at the beginning!
avail = count at the very beginning.

But the number of characters we can convert != the number of free
slots in the output buffer. At least not in the code:
If the first call of 
converter->read(array, outpos (= 0), avail = (count)) returns
0, then the code doubles the size of array:
jint new_size = 2 * (outpos + avail) = 2 * count
and sets avail to 
new_size - outpos = 2 * count - 0 = 2 * count.

The array bytes contains exactly count bytes to convert into exactly count
output characters - not 2 * count.

The second loop now tries to convert 2 * count bytes which is
clearly wrong or did i make a silly mistake?

> So to me it looks like the current code is ok.
Then i would be very wrong of course.

> Martin> Because there is a fall through in
> Martin> gnu::gcj::convert::Input_iconv::read for E2BIG the value
> Martin> returned by converter->read for done is 0.
> 
> We have some known problems in that code -- workarounds for iconv bugs
> in an earlier glibc.  The appended patch, which I still haven't
> checked in, will probably fix the bug you are seeing.  Could you try
> it?
I will try that, but it will take a while.

> glibc 2.1.3 is pretty old, and nobody responded to my query asking for
> testing when I first sent this patch out (I don't have such a system).
> So if this patch works for you, I'll check it in.

Just to make that clear: I have a Solaris 2.8 box here - there is no glibc involved
at all here.

Thanks for your time,
Martin.


-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.