You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Andrew (JIRA)" <ji...@apache.org> on 2008/09/17 04:17:46 UTC
[jira] Created: (GERONIMO-4307) Base64DecoderStream return int
value between -128 and +127, should be between +0 and +255
Base64DecoderStream return int value between -128 and +127, should be between +0 and +255
-----------------------------------------------------------------------------------------
Key: GERONIMO-4307
URL: https://issues.apache.org/jira/browse/GERONIMO-4307
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: specs
Affects Versions: 2.1.1
Environment: Geronimo 2.1.1 running on Ubuntu 7.10, Sun Java 1.5.
Reporter: Andrew
The documentation for InputStream specifies the following:
Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.
A subclass must provide an implementation of this method.
Note the second sentence. As Base64DecoderStream extends FilterInputStream, which in turn extends InputStream, it should be adhering to that.
However, it currently returns a byte directly, and because Java is a bit strange, it will do sign extension (I think that's the term?), so a byte of -1 will become an int of -1 as well, as opposed to an int of 255. As you might imagine, this causes all sorts of interesting problems when code tries to read the bytes from this stream and check for a negative value to determine EOS.
I imagine the fix for this is simply to change
public int read() throws IOException
{
return getByte();
}
to read
public int read() throws IOException
{
return getByte() & 0xFF;
}
Which is essentially what the Java class ByteArrayInputStream does.
Unless there is a good reason for this behaviour?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4307) Base64DecoderStream return int
value between -128 and +127, should be between +0 and +255
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire reassigned GERONIMO-4307:
--------------------------------------
Assignee: Rick McGuire
> Base64DecoderStream return int value between -128 and +127, should be between +0 and +255
> -----------------------------------------------------------------------------------------
>
> Key: GERONIMO-4307
> URL: https://issues.apache.org/jira/browse/GERONIMO-4307
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: specs
> Affects Versions: 2.1.1
> Environment: Geronimo 2.1.1 running on Ubuntu 7.10, Sun Java 1.5.
> Reporter: Andrew
> Assignee: Rick McGuire
>
> The documentation for InputStream specifies the following:
> Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.
> A subclass must provide an implementation of this method.
> Note the second sentence. As Base64DecoderStream extends FilterInputStream, which in turn extends InputStream, it should be adhering to that.
> However, it currently returns a byte directly, and because Java is a bit strange, it will do sign extension (I think that's the term?), so a byte of -1 will become an int of -1 as well, as opposed to an int of 255. As you might imagine, this causes all sorts of interesting problems when code tries to read the bytes from this stream and check for a negative value to determine EOS.
> I imagine the fix for this is simply to change
> public int read() throws IOException
> {
> return getByte();
> }
> to read
> public int read() throws IOException
> {
> return getByte() & 0xFF;
> }
> Which is essentially what the Java class ByteArrayInputStream does.
> Unless there is a good reason for this behaviour?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4307) Base64DecoderStream return int value
between -128 and +127, should be between +0 and +255
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire closed GERONIMO-4307.
----------------------------------
Resolution: Fixed
Committed revision 696241.
Nope, definitely a bug.
> Base64DecoderStream return int value between -128 and +127, should be between +0 and +255
> -----------------------------------------------------------------------------------------
>
> Key: GERONIMO-4307
> URL: https://issues.apache.org/jira/browse/GERONIMO-4307
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: specs
> Affects Versions: 2.1.1
> Environment: Geronimo 2.1.1 running on Ubuntu 7.10, Sun Java 1.5.
> Reporter: Andrew
> Assignee: Rick McGuire
>
> The documentation for InputStream specifies the following:
> Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.
> A subclass must provide an implementation of this method.
> Note the second sentence. As Base64DecoderStream extends FilterInputStream, which in turn extends InputStream, it should be adhering to that.
> However, it currently returns a byte directly, and because Java is a bit strange, it will do sign extension (I think that's the term?), so a byte of -1 will become an int of -1 as well, as opposed to an int of 255. As you might imagine, this causes all sorts of interesting problems when code tries to read the bytes from this stream and check for a negative value to determine EOS.
> I imagine the fix for this is simply to change
> public int read() throws IOException
> {
> return getByte();
> }
> to read
> public int read() throws IOException
> {
> return getByte() & 0xFF;
> }
> Which is essentially what the Java class ByteArrayInputStream does.
> Unless there is a good reason for this behaviour?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.