failure for the literal corpus on 32bit architectures

[boutil]

Hi,

In Debian, we see the failure on one test on architectures using 32bits.

Failures:

  1) Unparser corpus passes the literal corpus
     Failure/Error: expect(Unparser::CLI.run(%w[test/corpus/literal --literal] + version_excludes)).to be(0)

       expected #<Integer:1> => 0
            got #<Integer:3> => 1

       Compared using equal?, which compares object identity,
       but expected and actual are not the same object. Use
       `expect(actual).to eq(expected)` if you don't care about
       object identity in this example.
     # ./spec/unit/unparser_spec.rb:432:in `block (3 levels) in <top (required)>'
     # ./spec/spec_helper.rb:10:in `block in <top (required)>'

See for example
https://ci.debian.net/packages/r/ruby-unparser/testing/armel/55945480/
or
https://ci.debian.net/packages/r/ruby-unparser/testing/i386/55964357/

This is the actual diff between the expected and generated output. The difference is that in one hand, 1 is returned as an int, and in the other hand as a float.

--- unparser-old.txt	2025-01-31 18:25:56.381930232 +0100
+++ unparser-new.txt	2025-01-31 18:28:43.262964364 +0100
@@ -1,4 +1,4 @@
- Original-Source:
+ Generated-Source:
  { "foo" => <<-HEREDOC, "bar" => :baz }
    #{}
  HEREDOC
@@ -17,7 +17,7 @@
  ++1
  1
  1
- 1r
+ 1.0r
  1.5r
  1.3r
  5i
@@ -25,7 +25,7 @@
  0.6i
  -0.6i
  1000000000000000000000000000000i
- 1ri
+ 1.0ri
  "foo" "bar"
  "foobar #{baz}"
  "foo#{1}bar"

Do you know what could cause that? Thanks in advance

[mbj]

I guess that this is actually a behavior difference between ruby on 32 and 64 bit architectures. I first need to be able to reproduce it to attack it in a constructive way.

But I am not sure I consider it in scope of unparser the project. Thoughts?

I can probably reproduce it via using tools like qemu to get myself a 32 bit ruby. But this would be very low on my priority list unless someone gave me a good reason to spend my time on it.