.seek(... SeekFromCurrent) seeks to incorrect place if called after .readchars

[p6rt]

Migrated from rt.perl.org#130843 (status was 'resolved')

Searchable as RT130843$

[p6rt]

From @zoffixznet

If .seek(... SeekFromCurrent) is called after a call to .readchars, the position sought to appears to be way off target​:

  22​:54 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you so very much"; with "/tmp/Foo.pm6".IO.open { .read(2); .seek​: 1, SeekFromCurrent; .tell.say }
  22​:54 camelia rakudo-moar 5ec251​: OUTPUT​: «3␤»
  22​:55 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you so very much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1, SeekFromCurrent; .tell.say }
  22​:55 camelia rakudo-moar 5ec251​: OUTPUT​: «24␤»
  22​:55 IOninja looks .readchars messes up the current position as far as seekage is concerned (it's fine if you try to read more, for example)

After some discussion on IRC (https://irclog.perlgeek.de/perl6-dev/2017-02-22 ), one suggestion was that there's some sort of buffering involved​:

  23​:00 m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1, SeekFromCurrent; .tell.say }
  23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «24␤»
  23​:00 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very much" x 100; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1, SeekFromCurrent; .tell.say }
  23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «2301␤»
  23​:00 jnthn Anyway, just sayin' that if it's off-by-one it's actually not lying :)
  23​:00 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very much" x 10000; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1, SeekFromCurrent; .tell.say }
  23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «32769␤»
  23​:00 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very much" x 20000; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1, SeekFromCurrent; .tell.say }
  23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «32769␤»

This behaviour is not present on JVM.

[p6rt]

From @dogbert17

On Wed, 22 Feb 2017 15​:09​:44 -0800, cpan@​zoffix.com wrote​:

If .seek(... SeekFromCurrent) is called after a call to .readchars,
the position sought to appears to be way off target​:

22​:54 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you so very
much"; with "/tmp/Foo.pm6".IO.open { .read(2); .seek​: 1,
SeekFromCurrent; .tell.say }
22​:54 camelia rakudo-moar 5ec251​: OUTPUT​: «3␤»
22​:55 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you so very
much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1,
SeekFromCurrent; .tell.say }
22​:55 camelia rakudo-moar 5ec251​: OUTPUT​: «24␤»
22​:55 IOninja looks .readchars messes up the current position as
far as seekage is concerned (it's fine if you try to read more, for
example)

After some discussion on IRC (https://irclog.perlgeek.de/perl6-
dev/2017-02-22 ), one suggestion was that there's some sort of
buffering involved​:

23​:00 m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very
much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1,
SeekFromCurrent; .tell.say }
23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «24␤»
23​:00 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very
much" x 100; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1,
SeekFromCurrent; .tell.say }
23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «2301␤»
23​:00 jnthn Anyway, just sayin' that if it's off-by-one it's
actually not lying :)
23​:00 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very
much" x 10000; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1,
SeekFromCurrent; .tell.say }
23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «32769␤»
23​:00 IOninja m​: "/tmp/Foo.pm6".IO.spurt​: "I love you\nso very
much" x 20000; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek​: 1,
SeekFromCurrent; .tell.say }
23​:00 camelia rakudo-moar 5ec251​: OUTPUT​: «32769␤»

This behaviour is not present on JVM.

The fixes, and tests, made by Zoffix, when fixing https://rt.perl.org/Public/Bug/Display.html?id=131376
covers this bug as well.

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

@dogbert17 - Status changed from 'open' to 'resolved'