<rant>
These 2+ hour email delivery times are getting to be a real pain. It's
almost impossible to have multi-party communication with such delays.
</rant>
Revision 1.5.2.4 was commited by Keith and fixed a real problem. doRead()
should return the integer -1 when EOF is reached. However, if the byte just
read happens to be 0xFF then the conversion from byte to int (for the
return) would sign extend the 0xFF value into the integer -1, thus falsely
indicating EOF. Casting the byte to a char type avoided the sign extension
because chars are unsigned in Java.
The byte array filled in by the other doRead() method does not suffer from
this problem because the method will only return -1 if there was no more
data. Now, the byte array will contain 0xFF bytes and depending on how
higher level processing handles them they might cause other problems, but at
this layer everything looks OK. That's why I asked for a clarification. I
don't see how the proposed changes would actually alter the outcome.
> -----Original Message-----
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 17, 2001 10:51 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Servlet Upload Data Corruption
>
>
> >Could you explain a little more what these diffs accomplish? My
> >understanding of the fix that went into revision 1.5.2.4 to
> >fix the file upload problem was that doRead() returns an 'int' and was
> >causing the byte >0xFF to be sign extended into the integer -1
> which is the
> EOF
> >return value for doRead().
>
> Commited by Dan or Keith ?)
>
> >The byte array version of doRead() should only
> >return -1 if
> >there really isn't any more data. The actualy contents of the
> >bytes read, because they aren't interpretted, don't matter at all.
>
> The problem is related to encoding ?)
> How did the data are then passed (and translated)
> from byte[] to the servlet ?
>
> >I don't see how the byte array returned is any different in the patched
> >version then what it was before. Converting a byte into a
> >char and then masking off all but the lowest 8 bits and then turning the
> >results back into a byte looks like a no-op to me.
>
> +1
