Alan Hudson wrote:
>>>> Not enough info to tell if this is a encoding or decoding issue.
>>>>
>>>> _octetBufferStart should never be decremented. It defines the
>>>> starting index the octets of encoding algorithm data in the
>>>> _octetBuffer.
>>>>
> if _octetBufferStart never decrements then the array must keep growing.
> Calls like this are made to the decoders:
> decodeFromBytes(_octetBuffer, _octetBufferStart,
> _octetBufferLength);
>
> So if octeBufferStart never goes back to zero then octetBuffer must
> always grow.
> Should these calls be using _octetBufferOffset... that gets zeroed
> during ensureOctetBufferSize().
>
_octetBufferStart is set by the methods:
decodeOctetsOfNonIdentifyingStringOnFirstBit
decodeOctetsOfNonIdentifyingStringOnThirdBit
in the following manner:
_octetBufferStart = _octetBufferOffset;
ensureOctetBufferSize();
_octetBufferOffset += _octetBufferLength;
I think i know the problem. The ensureOctetBufferSize method checks if
the the complete sequence of octets of the algorithm data are present in
the buffer. If not it does one of two things:
1) Move the sequence of octets of the algorithm data in the buffer to
the start to make room for the remaining octets that need to be read; or
2) Resize the buffer and do 1).
and then fills up the rest of the buffer with a read of the underlying
stream.
In either case the _octetBufferStart will be rendered invalid if 1)
occurs. It needs to be set after the the ensureOctetBufferSize() call.
Paul.
>>
>> There could be something wrong with the Decoder.ensureOctetBufferSize
>> method.
>>
> I don't see a way this buffer won't just keep growing over time. I'd
> assume after an algorithm is done the _octetBufferStart would go back to
> zero?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_fi.dev.java.net
> For additional commands, e-mail: dev-help_at_fi.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109