On Mon, 17 Oct 2022 11:14:35 GMT, Alan Bateman <al...@openjdk.org> wrote:
>>> > @AlanBateman WDYT? Is such a test mandatory to include this rather simple >>> > PR? >>> >>> I think it means checking that >>> test/jdk/java/io/BufferedInputStream/TransferTo.java exercises this code >>> path, I expect it should. >>> >>> It might seem a "rather simple PR" but it leaks a reference to the internal >>> buffer to the target and we need to get comfortable with that. It only does >>> then when there is no mark (good) so this should mostly limit the concern >>> to sources where EOF may be encountered more than once. >> >> Which kind of sources would do that, and is there a way to check it and >> prevent it? >> >> The whole issue points to an insufficiency in the API: it is lacking a way >> to transfer buffers in a read-only fashion (like NIO could do). I don't >> suppose we would want to change that, though, right? > >> Which kind of sources would do that, and is there a way to check it and >> prevent it? >> >> The whole issue points to an insufficiency in the API: it is lacking a way >> to transfer buffers in a read-only fashion (like NIO could do). I don't >> suppose we would want to change that, though, right? > > It can arise with many sources. One example is a program writing to a file > and another reading from the same file and doing the equivalent of "tail -f". > So yes, it is possible for transferTo to transfer >0 bytes after it a > previous innovation has returned 0. @AlanBateman To progress with this PR, what do you expect me to do? Do you want me to provide a test that proofs that this particular example will work fine? Or do you like me to simply copy the buffer instead of leaking it? ------------- PR: https://git.openjdk.org/jdk/pull/10525
