[
http://issues.apache.org/jira/browse/DIRMINA-242?page=comments#action_12430751
]
Pavel Zdenek commented on DIRMINA-242:
--------------------------------------
You are right, there is no difference. Method getString(int, CharsetDecoder) is
not vulnerable to this problem. The test case would be your existing
testGetString(), only allocating a buffer of exact size for the test string,
i.e.
public void testGetString() throws Exception
{
ByteBuffer buf = ByteBuffer.allocate( 4 );
... instantiate ISO decoder...
... put ABC\0 ....
buf.position( 0 );
Assert.assertEquals( 4, buf.getString( decoder ) );
}
Assert fails, because string includes trailing zero. The condition is when the
trailing zero is the last character in the buffer (i.e. position after reading
equals capacity ).
SECONDLY, sorry for mixing two requests in one issue. The bug above is NOT my
primary request, as i have a bypass implementation for 0.8 and it's fixed in
0.9. I would like to have a method
ByteBuffer.getString(int fieldSize, CharsetDecoder decoder, boolean stopOnZero )
which would (on stopOnZero==false) forward the buffer position up to the field
size, even if the ASCIIZ string has ended earlier. The purpose has been
explained in the first comment. So far, reading any values from a buffer of
simple protocol with fixed-length values is very clean and understandable,
except strings.
> ByteBuffer.getString(ByteBuffer buf, int fieldSize, CharsetDecoder decoder,
> boolean stopOnZero )
> ------------------------------------------------------------------------------------------------
>
> Key: DIRMINA-242
> URL: http://issues.apache.org/jira/browse/DIRMINA-242
> Project: Directory MINA
> Issue Type: New Feature
> Affects Versions: 0.8.2
> Reporter: Pavel Zdenek
> Priority: Trivial
>
> The method would read an ASCIIZ string off the buffer as the existing method
> without added parameter.
> If stopOnZero is false, it would continue blindly reading the stream up to
> the required fieldSize.
> So far MINA has no support for reading fixed (small) size strings. This is
> common for protocols constructed at devices with limited resources (i.e.
> network attached microcontrollers) and above the mandatory ending zero may be
> whatever garbage left from previous memory usage.
> My temporary implementation follows, to get the idea.
> It also solves the problem with getString behavior when reading ASCIIZ at the
> end of buffer (apparently fixed in dev 0.9)
> public static String getString(ByteBuffer buf, int fieldSize,
> CharsetDecoder decoder, boolean stopOnZero )
> throws CharacterCodingException
> {
> if( fieldSize == 0) fieldSize = buf.remaining(); // convenience "0 ~
> till the end"
> int origLimit = buf.limit();
> int posStrEnd = 0;
> buf.mark(); // beginning of string
> boolean foundZero = false;
> while(buf.hasRemaining() && (fieldSize-- > 0) )
> {
> if( (buf.get() == 0) && !foundZero )
> {
> foundZero = true;
> posStrEnd = buf.position()-1;
> if( stopOnZero ) break;
> }
> }
> int reachedPos = buf.position(); // later must return here
> buf.reset(); // position to string begin
> if(foundZero) buf.limit( posStrEnd );
> String str = buf.getString(decoder);
> if(foundZero) buf.limit(origLimit);
> buf.position(reachedPos);
> return str;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
