[
https://issues.apache.org/jira/browse/IO-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcono1234 updated IO-716:
---------------------------
Description:
{{org.apache.commons.io.input.ReaderInputStream}} enters an infinite loop when
it was constructed with a too small buffer size (0 or 1) and one of its reading
methods is called.
Example:
{code}
int bufferSize = 1;
try (InputStream in = new ReaderInputStream(new StringReader("\uD800"),
StandardCharsets.UTF_8, bufferSize)) {
in.read();
}
{code}
This could be solved by making sure that the buffer size is always >= 1. This
should solve this issue because as far as I know all charsets only report
{{UNDERFLOW}} without encoding any chars if the only char in the buffer is a
surrogate.
However, the saner solution might be to increase the buffer when {{UNDERFLOW}}
is encountered and {{encoderIn}} has not changed.
----
Similarly for sanety it would be good to throw an {{AssertionError}} (or
increase the size of {{encoderOut}}) if {{OVERFLOW}} is returned. I don't think
there are any encodings which require more than 128 bytes (used by
{{ReaderInputStream}} for the output buffer) for encoding a single char or
flushing, but would be good to at least handle that case in a saner way than
entering an infinite loop anyways.
was:
{{org.apache.commons.io.input.ReaderInputStream}} enters an infinite loop when
it was constructed with a too small buffer size (0 or 1) and one of its reading
methods is called.
Example:
{code}
int bufferSize = 1;
try (InputStream in = new ReaderInputStream(new StringReader("\uD800"),
StandardCharsets.UTF_8, bufferSize)) {
in.read();
}
{code}
This could be solved by making sure that the buffer size is always >= 1. This
should solve this issue because as far as I know all charsets only report
{{UNDERFLOW}} without encoding any chars if the char is a surrogate.
However, the saner solution might be to increase the buffer when {{UNDERFLOW}}
is encountered and {{encoderIn}} has not changed.
----
Similarly for sanety it would be good to throw an {{AssertionError}} (or
increase the size of {{encoderOut}}) if {{OVERFLOW}} is returned. I don't think
there are any encodings which require more than 128 bytes (used by
{{ReaderInputStream}} for the output buffer) for encoding a single char or
flushing, but would be good to at least handle that case in a saner way than
entering an infinite loop anyways.
> ReaderInputStream enter infinite loop for too small buffer sizes
> ----------------------------------------------------------------
>
> Key: IO-716
> URL: https://issues.apache.org/jira/browse/IO-716
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
> Affects Versions: 2.8.0
> Reporter: Marcono1234
> Priority: Major
>
> {{org.apache.commons.io.input.ReaderInputStream}} enters an infinite loop
> when it was constructed with a too small buffer size (0 or 1) and one of its
> reading methods is called.
> Example:
> {code}
> int bufferSize = 1;
> try (InputStream in = new ReaderInputStream(new StringReader("\uD800"),
> StandardCharsets.UTF_8, bufferSize)) {
> in.read();
> }
> {code}
> This could be solved by making sure that the buffer size is always >= 1. This
> should solve this issue because as far as I know all charsets only report
> {{UNDERFLOW}} without encoding any chars if the only char in the buffer is a
> surrogate.
> However, the saner solution might be to increase the buffer when
> {{UNDERFLOW}} is encountered and {{encoderIn}} has not changed.
> ----
> Similarly for sanety it would be good to throw an {{AssertionError}} (or
> increase the size of {{encoderOut}}) if {{OVERFLOW}} is returned. I don't
> think there are any encodings which require more than 128 bytes (used by
> {{ReaderInputStream}} for the output buffer) for encoding a single char or
> flushing, but would be good to at least handle that case in a saner way than
> entering an infinite loop anyways.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
