Closed postmodern closed 2 years ago
Just tested on truffleruby 22.1.0 and seeing the same behavior.
Thank you for the report.
@aardvark179 Can you take a look?
I'll take a look.
It's quite weird .unpack('Z')
doesn't consume the \0
on CRuby, even though it obviously reads it. Sounds very error-prone.
It's easy to be compatible with CRuby for that, though.
A fix for this has now been merged into master (b1dbba7fff2208a3eecd16eb653c086af8a19558).
One of my specs which tests unpacking a repeating series of binary fields fails on truffleruby. I managed to narrow the bug down to using
Z
andx
in a pack-string along withs
andL
after it. Changing theZ
to anA
or removing thex
and the\x00
byte seems to work, implying there's some kind of interaction between the handling ofZ
andx
.Steps To Reproduce
Expected Result
Actual Result
Versions
truffleruby 22.0.0.2, like ruby 3.0.2, GraalVM CE Native [x86_64-linux]
truffleruby 22.1.0, like ruby 3.0.2, GraalVM CE Native [x86_64-linux]
Additional Insights
If we add another
x
and another\x00
along with aL
and\xFF\xFF\xFF\xFF
we get this strange result:If we pack
16777215
as an unsigned 32bit integer (L
) we get these bytes:This seems to imply there's an off-by-one error in the
String#unpack
logic caused byx
.