Project

General

Profile

Actions
Copy link

Bug #18377

closed

Integer#times has different behavior depending on the size of the integer

Added by jemmai (Jemma Issroff) almost 3 years ago. Updated almost 3 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
3.0.2
Backport:
2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
[ruby-core:106361]

Description

If we redefine + or >, Integer#times adheres to this redefinition for big integers but not for small integers.

Reproduction script to run on Ruby 3.0.2:

ARGV.first.to_i.times do
  Integer.undef_method(:+)
  Integer.define_method(:+) do |_other|
    puts "my custom add"
    exit
  end
end

Using 1 as an argument has no printed output:

$ ruby test_add.rb 1

whereas using 2 ** 64 (18446744073709551615) prints "my custom add":

$ ruby test_add.rb 18446744073709551615
my custom add

We see the same difference when we override behavior of <:

ARGV.first.to_i.times do
  Integer.undef_method(:<)
  Integer.define_method(:<) do |_other|
    puts "my custom less than"
    exit
  end
end

$ ruby test_less_than.rb 1

$ ruby test_less_than.rb 18446744073709551615
my custom less than

Note that the boxed number which changes the Integer#times behavior will vary on different machines.

Options

There are three potential paths forward here:

  1. Change behavior for small integers to match behavior for big integer.
    This will have a performance cost. It’s uncommon to redefine + or < on Integers. For this reason, I would argue that correctness on an obscure edge case (especially one that has been unreported since almost the beginning of the language) is less important than performance on the default case.

  2. Change behavior for big integers to match behavior for small integers.
    This will mean that behavior is incorrect on both big integers and small integers, but at least it is consistent. Right now it is arbitrary and hard to explain why the behavior would change based on the integer itself. If we keep this behavior consistent for all integers, we can document this clearly in a way that is easy to understand.

  3. Do nothing.
    This bug has existed for many years unreported. The last option is to not pursue any code changes, but potentially document this behavior.

Proposal

I propose we pursue option 2 and make the behavior consistent and documented. As I said, it’s unlikely that developers override integer behavior of +, and especially unlikely to do this within an Integer#times block. As long as this is documented and consistent, it seems okay to me to have this known incorrectness to save the performance cost of accommodating different definitions of +.

Actions
Copy link

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0