Certainly some verbiage like that could be added.
Going back to last month in the discussion about improving the performance of
readAllBytes() I calculated the exact number of bytes allocated [1]. For the
initial implementation in that change this was
B + L for L <= B
N =
B + 2*L for L > B
where B is the internal buffer size and L is len. I would need to double check
the accuracy of the above but I think your suggestion of “proportional” is
sufficient.
Thanks,
Brian
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050686.html
On Jan 22, 2018, at 7:56 AM, Adam Petcher <[email protected]> wrote:
> The spec of the new method doesn't give me enough information to determine
> whether it is safe to call it when the value of the length argument is much
> larger than the number of bytes I expect to actually read. This use case
> comes up frequently in security libraries, because we have to handle length
> values that were chosen by an attacker. Would it be possible to add a
> sentence or two to the spec to clarify this situation?
>
> Possible wording, if this method can be called with large length values:
>
> "The total amount of memory allocated by this method is proportional to the
> number of bytes read from the stream. Therefore, the method may be safely
> called with very large values of {@code len}.
>
> Possible wording, otherwise:
>
> "The total amount of memory allocated by this method may be proportional to
> the value of {@code len}. Therefore, calling this method with very large
> values of {@code len} is not recommended."
