[ http://issues.apache.org/jira/browse/DIRMINA-242?page=comments#action_12432600 ] Pavel Zdenek commented on DIRMINA-242: --------------------------------------
The request is not to get EVERYTHING of length fieldSize as "the one" return string, including nulls and all garbage. "This" ByteBuffer is expected to REALLY hold a VALID ASCIIZ string at the current position. Method would use CharsetDecoder on it and save it as return value, just like the current method does. I only want the method to return AFTER this ByteBuffer is at the right position for get()-ting the next entity, just like with any other fixed-length value (primitives, arrays, etc.). Even when the spoken string has not occupied entire _fixed_ space allocated for it in the protocol. So above the ending null, just forward the position, not storing anything. In the application which is the reason for all this fuss, i have a stream of 5-bytes chunks, each holding a string of 1-5 chars,mostly 4. The sender is an average microcontroller and the clean way (sending a string length and then just the appropriate number of bytes, resulting in variable length of chunks) would be worse in terms of code size and volatile memory requirements. > 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
