tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
Date Mon, 03 Mar 2008 22:58:35 GMT
Remy Maucherat wrote:
> On Mon, 2008-03-03 at 21:13 +0000, Mark Thomas wrote:
>   
>> Filip Hanik - Dev Lists wrote:
>>     
>>> Mark Thomas wrote:
>>>       
>>>> Remy Maucherat wrote:
>>>>         
>>>>> On Thu, 2008-02-28 at 01:36 +0100, Remy Maucherat wrote:
>>>>>           
>>>>>> Index: java/org/apache/catalina/connector/InputBuffer.java
>>>>>>
>>>>>>             
>> ===================================================================
>>     
>>>>>> ---java/org/apache/catalina/connector/InputBuffer.java
>>>>>>             
>> (revision 
>>     
>>>>>> 630535)
>>>>>> +++java/org/apache/catalina/connector/InputBuffer.java
>>>>>>             
>> (working 
>>     
>>>>>> copy)
>>>>>> @@ -355,7 +355,7 @@
>>>>>>          }
>>>>>>  
>>>>>>          state = CHAR_STATE;
>>>>>> -        conv.convert(bb, cb, len);
>>>>>> +        conv.convert(bb, cb, bb.getLength());
>>>>>>          bb.setOffset(bb.getEnd());
>>>>>>  
>>>>>>          return cb.getLength();
>>>>>>             
>>>>> This seems to work for me. It should be equivalent to the value
>>>>>           
>> returned
>>     
>>>>> by the available method, since the value passed is the same (it is
>>>>>           
>> the
>>     
>>>>> amount of bytes which have been read).
>>>>>           
>>>> Just to be clear, do you mean that the above patch 
>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=44494  ?
>>>>         
>>> that's correct
>>> Filip
>>>       
>> First off - sorry it has taken me a few days to reply.
>>
>> Secondly, I still haven't had enough time to look at this in detail so
>> my 
>> reasoning may be way off base. It it is, I apologise - feel free to
>> correct 
>> me with or without flames.
>>
>> Looking through the InputBuffer code, realReadBytes(), realReadChars()
>> and 
>> realWriteChars() all ignore the parameters passed in with the
>> exception of 
>> len in realReadChars() which the patch above changes so it too is
>> ignored.
>>
>> It appears to me that all of these methods need to be modified not to
>> take 
>> any parameters since they all operate on the internal buffers rather
>> than 
>> the ones passed to them (a job for another day). On this basis, the
>> patch 
>> above patch strikes me as the right way forward rather than the one 
>> currently applied to trunk.
>>     
>
> This problem is a small detail. Much more should be done if you want to
> do a refactoring: both the mark functionality and readLine need to have
> direct access to the buffer to be able to be coded in a sane way (and be
> more efficient too).
>   
yes, so the question is for 6.0.x and 5.5.x, do we wanna proceed down 
the refactor route?
I was against it in the beginning for the fear of regression. I 
personally think the whole bytechunk/charchunk thing is very complex, 
and can be done easier, but that is something I would play around in 
sandbox, and eventually bring into trunk if it was working.

for 6.0.x and 5.5.x, I'd rather keep the fixes to the actual bug fix to 
maintain stability

Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message