August 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:122817] [Ruby Bug#21517] Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial
by herwin (Herwin W) 03 Aug '25

03 Aug '25

Issue #21517 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21517: Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial https://bugs.ruby-lang.org/issues/21517 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] (+ others) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The specs for `IO#readpartial` have the following test (https://github.com/ruby/spec/blob/ed254bae321221f5cd24280beb37e5bddaff6bb6/…) ```ruby before :each do @rd, @wr = IO.pipe @rd.binmode @wr.binmode end it "reads after ungetc with multibyte characters in the buffer" do @wr.write("∂φ/∂x = gaîté") c = @rd.getc @rd.ungetc(c) @rd.readpartial(3).should == "\xE2\x88\x82" @rd.readpartial(3).should == "\xCF\x86/" end ``` This behaviour is different in `StringIO#readpartial`. If I add this as a spec: ```ruby it "reads after ungetc with multibyte characters in the buffer" do @string = StringIO.new(+"∂φ/∂x = gaîté") c = @string.getc @string.ungetc(c) @string.readpartial(3).should == "\xE2\x88\x82" @string.readpartial(3).should == "\xCF\x86/" end ``` it fails with every supported Ruby version, and even with 3.5-dev of today, with the message `Expected "\xE2\x88\x82" == "∂"` The `getc` + `ungetc` can be removed, but this does not change the behaviour. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:122897] [Ruby Feature#21526] cryptocurrency & cybersecurity
by umershafique89＠gmail.com (Muhammad umar) 01 Aug '25

01 Aug '25

Issue #21526 has been reported by umershafique89(a)gmail.com (Muhammad umar). ---------------------------------------- Feature #21526: cryptocurrency & cybersecurity https://bugs.ruby-lang.org/issues/21526 * Author: umershafique89(a)gmail.com (Muhammad umar) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122892] [Ruby Bug#21525] Inconsistent execution order for methods with constant blocks
by joel＠drapper.me (Joel Drapper) 01 Aug '25

01 Aug '25

Issue #21525 has been reported by joel(a)drapper.me (Joel Drapper). ---------------------------------------- Bug #21525: Inconsistent execution order for methods with constant blocks https://bugs.ruby-lang.org/issues/21525 * Author: joel(a)drapper.me (Joel Drapper) * Status: Open * ruby -v: ruby 3.4.5 (2025-08-01 revision 07f7832cff) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- If you call a method and pass in a splat of an array with a block argument coerced from calling a method, Ruby maintains the expected execution order and the called method receives a copy of the array prior to modification. In this example, the output is `[1, 2, 3]` since the copy is made before the `bar` method can modify it. ```ruby ARRAY = [1, 2, 3] def bar ARRAY.pop -> {} end def example(*args, &) puts args end example(*ARRAY, &bar) ``` However, when passing a constant, the block coercion itself is able to modify the array. ```ruby ARRAY = [1, 2, 3] module Foo module Bar def self.to_proc ARRAY.pop -> {} end end end def example(*args, &) puts args end example(*ARRAY, &Foo::Bar) ``` Another way to trigger this is to define a `const_missing` method that modifies the array. ```ruby ARRAY = [1, 2, 3] module Foo def self.const_missing(name) ARRAY.pop -> {} end end def example(*args, &) puts args end example(*ARRAY, &Foo::Bar) ``` In both these cases, the output is `[1, 2]` instead of the expected `[1, 2, 3]`. -- https://bugs.ruby-lang.org/

2 2