July 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125586] [Ruby Feature#22085] `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings
by byroot (Jean Boussier) 09 Jul '26

09 Jul '26

Issue #22085 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22085: `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings https://bugs.ruby-lang.org/issues/22085 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Ruby issue warnings when parsing out of range floats, e.g.: ``` $ ruby -We '1e184467440737095516160.to_s' -e:1: warning: Float 1e184467440737095516... out of range ``` This makes a lot of sense for float literals parsed by the Ruby parser. However I'm not convinced it makes sense when parsing user input or third party data: ```ruby >> '1e184467440737095516160'.to_f (irb):1: warning: Float 1e184467440737095516... out of range => Infinity >> Float('1e184467440737095516160') <internal:kernel>:196: warning: Float 1e184467440737095516... out of range => Infinity ``` As these warnings aren't really actionable in most cases. So I think `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:126026] [Ruby Misc#22180] Provide official Windows (mswin) binary packages and a version manager
by matz (Yukihiro Matsumoto) 09 Jul '26

09 Jul '26

Issue #22180 has been updated by matz (Yukihiro Matsumoto). I approve all three asks: making these official distribution artifacts on ruby-lang.org, signing them with a project identity, and hosting `rbmanager` under the `ruby` organization. The lack of an official Windows distribution has been a weak point of Ruby for decades, and this proposal fixes it for the very platform the core team builds and tests on, without competing with the existing gcc-based distributions. The fact that everything is already implemented and verified, and rides on the release automation hsbt already operates, makes this an easy decision. Details such as the vcruntime bundling question can be settled among the people already discussing them. Matz. ---------------------------------------- Misc #22180: Provide official Windows (mswin) binary packages and a version manager https://bugs.ruby-lang.org/issues/22180#change-118005 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Japanese version of this proposal: https://gist.github.com/hsbt/552b01f2aac616af6f8056148407900a ## Background Ruby used to ship official Windows binaries. https://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ still has mswin32 zips from the 1.6 to 1.9-preview era, and they were discontinued around 1.9. One reason is that a bare zip was not usable as a distribution. https://bugs.ruby-lang.org/issues/999 reports that the `ruby-1.9.1-preview1` mswin32 zip was missing the OpenSSL and zlib DLLs, so `gem update` did not work at all. Since then, installing Ruby on Windows has depended on third-party distributions. The mswin platform, which is what `ruby/ruby` CI actually builds and tests with MSVC, has had no end-user distribution at all. https://bugs.ruby-lang.org/issues/19325 shows how the current state is perceived by Windows users. The technical ground has changed. Over the last few months I fixed all the tests that remained broken on mswin myself: `nmake check`, `test-bundler` and `test-bundled-gems` are green now, and `nmake exam`, which runs all of the test suites, completes as well. The build manages its C dependencies with a pinned vcpkg manifest (`vcpkg.json`), and CI covers VS 2022, VS 2026 and `windows-11-arm`. MSVC ABI (`vcruntime140`) has been stable since 2015. The missing piece is distribution, not build quality. Timing also matters. In the era of writing code with AI, the people who need a working Ruby on Windows are increasingly ordinary users who let a coding assistant set up the environment for them, and consumer AI tools operate natively on Windows, not through WSL. An assistant working unattended needs a runtime that installs without elevation and without GUI dialogs, exposes a machine-readable version index, and is relocatable so that installs are deterministic. Unattended provisioning is already the norm in CI (`setup-ruby` exists precisely for this), and AI assistants bring the same requirement to end-user machines. Python reached the same conclusion with PEP 773, described below. Ruby has no official answer to this on Windows today. ## Proposal I propose to provide an official Windows distribution based on the mswin platform, made of three components. All of them, including the test-suite fixes above, are work I implemented and verified myself. Nothing below is a design on paper. **1. `ruby/ruby`: a `binary-package` target.** A new nmake-only target packages the installed tree together with the vcpkg runtime DLLs, the VC runtime and the license terms of everything redistributed into a relocatable zip, with build-machine specific paths scrubbed from `rbconfig.rb`. Thanks to `LOAD_RELATIVE` the tree runs from any location. I will submit the pull request shortly. This is implemented and verified. The package passes a smoke test with `PATH` restricted to `System32` (openssl, fiddle, psych, zlib and RubyGems all work), and C extensions compile with VS Build Tools. In a survey of the 500 most-downloaded gems on rubygems.org forced to build from source, 21 of the 44 gems with a native extension built and loaded. All 23 failures were gem-side or environment-side issues (gcc-only code, POSIX-only source, missing third-party libraries), none caused by the package or by ruby itself, with identical results on 3.3.11, 3.4.10 and 4.0.5. **2. `ruby/actions`: building and publishing.** Automation builds the zips and publishes them together with sha256 checksums: daily builds of master and release builds of the maintained series. Released series (3.3, 3.4, 4.0) are built from their release tarballs with the same packaging script applied externally, so no change to the stable branches is required. This also enables re-packaging revisions (`-1`, `-2`) when a bundled dependency such as OpenSSL needs a security update without a new Ruby release. This part is already working too: in addition to master, zips of 3.3.11, 3.4.10 and 4.0.5 have been built and verified this way, and they are the packages the gem survey above was run on. **3. `rbmanager`: a version manager for Windows.** The same shape as Python's install manager (PEP 773, https://peps.python.org/pep-0773/) A single native executable (the `rb` command) installs a zip from a URL or a local path, extracts it under `%LOCALAPPDATA%`, switches versions with an NTFS junction, and needs one user-level `PATH` entry and no elevation. A working prototype written in C# is already complete and verified on a real machine: ``` > rb install ruby-4.1.0-x64-mswin64_140.zip Extracting ruby-4.1.0-x64-mswin64_140 ... Installed ruby-4.1.0-x64-mswin64_140 > ruby -v ruby 4.1.0dev (2026-06-29T22:22:44Z master 2ce6b8e54a) +PRISM [x64-mswin64_140] > rb list ruby-3.3.11-x64-mswin64_140 ruby-3.4.10-x64-mswin64_140 ruby-4.0.5-x64-mswin64_140 * ruby-4.1.0-x64-mswin64_140 > rb use 4.0 Now using ruby-4.0.5-x64-mswin64_140 > ruby -v ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x64-mswin64_140] ``` The example installs from a local zip today. Once the official version index described below is published, `rb install 4.1` will resolve the version, download the zip and verify its checksum by itself. ## What building on the platform vendor's toolchain enables This proposal is complementary to the existing gcc-based distributions and does not compete with them. Some capabilities are decided by third-party vendors rather than by Ruby, because their SDKs assume the MSVC toolchain and ABI, and those become reachable with an official MSVC-built runtime. Machine-learning runtime assets become directly reusable: the prebuilt Windows packages of ONNX Runtime, libtorch and OpenCV are MSVC binaries with C++ ABIs, and CUDA's `nvcc` accepts only `cl.exe` as its host compiler on Windows, so Ruby extensions binding GPU and ML runtimes need an MSVC-built Ruby to link cleanly. PDB symbols connect Ruby to the standard Windows diagnostics stack: WinDbg and Visual Studio can debug a mixed stack of Ruby and vendor DLLs, WER minidumps from end users become analyzable, and publishing official symbol packages becomes possible for the first time. And extension authors can pull C dependencies from the same vcpkg ecosystem that `ruby/ruby` itself already uses through `vcpkg.json`. ## What I ask to decide First, make these official distribution artifacts: announce them on the www.ruby-lang.org download page and host the zips, checksums and a static version index (the equivalent of pymanager's `index-windows.json`) on ruby-lang.org infrastructure. GitHub Releases can serve as the initial hosting during the preview period. Second, sign the published binaries with a project identity (for example SignPath Foundation issues OSS code-signing certificates) rather than an individual certificate. Third, host `rbmanager` as a repository under the `ruby` organization. The concrete zip layout and naming rule are implementation details. I will work them out with @nobu and document the result in `doc/distribution/windows.md`, so they are not something to decide on this ticket. ## Scope and non-goals This proposal does not replace or deprecate any existing third-party distribution. It adds an official channel for the platform the core team itself builds and tests. I already operate the official snap distribution and the entire release pipeline including security releases, and these artifacts ride on the same automation and the same operator, so this proposal does not change the current maintenance level. Pure-Ruby gems work with no toolchain. Building a C extension requires VS Build Tools, which Microsoft has licensed for building open-source dependencies without a paid Visual Studio license since 2022, and a `ridk`-like bootstrap (`win32/install-buildtools.cmd` is the seed) is follow-up work. Precompiled `x64-mswin64` gems across the ecosystem are long-term work and not a prerequisite. The survey above identified 12 gems that already support Windows with `x64-mingw-ucrt` precompiled binaries and only lack a working MSVC source path, a concrete and small upstream fix list. That list includes nokogiri and ffi, so applications depending on them (Rails, for example) do not work on this distribution yet. The fixes are tractable: I have already verified a one-line fix for msgpack locally and will send these upstream. TLS trust anchors are not bundled in the zip. `rbmanager` provisions certificates from the Windows certificate store at install time, and I will separately propose `OpenSSL::X509::Store#add_store` support for the OpenSSL 3.2+ `org.openssl.winstore://` store in ruby/openssl as the permanent solution. x64 comes first. arm64 (`arm64-mswin64`) already builds in CI and will follow once its test suite is green. ## Roadmap The rollout is incremental rather than tied to a single date. Zips for the released series (3.3, 3.4, 4.0) will be published progressively for their existing releases. For 4.1, nightly zips of master are published continuously, and a zip follows each preview release as soon as it is out. Only the GA of `rbmanager` and the distribution mechanism as a whole is aligned with the Ruby 4.1 release in December. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 09 Jul '26

09 Jul '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125889] [Ruby Feature#22136] `sprintf` shouldn't raise ArgumentError when $DEBUG is set
by byroot (Jean Boussier) 09 Jul '26

09 Jul '26

Issue #22136 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22136: `sprintf` shouldn't raise ArgumentError when $DEBUG is set https://bugs.ruby-lang.org/issues/22136 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Expected behavior If I'm tracking down a problem and suspect an error might be swallowed somewhere, I do run my test case with `RUBYOPT="-d"` (or simply set `$DEBUG = true`. I do expect the program to execute all in the same way than without `-d`, expect for extra output on STDERR. ### Actual behavior If some code happens to call `sprintf` or `String#%` with too many arguments, then it will raise an error and likely break the program, preventing me from simply running the same code but in debug mode. ### Reproduction ``` $ ruby -e 'sprintf("foo", "bar"); p :ok' :ok $ ruby -We 'sprintf("foo", "bar"); p :ok' -e:1: warning: too many arguments for format string :ok $ ruby -dWe 'sprintf("foo", "bar"); p :ok' Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1423 - cannot load such file -- rubygems/defaults/operating_system Exception 'LoadError' at .../lib/ruby/4.0.0/rubygems.rb:1438 - cannot load such file -- rubygems/defaults/ruby Exception 'ArgumentError' at -e:1 - too many arguments for format string Exception 'RuntimeError' at <internal:ast>:96 - cannot get AST for ISEQ compiled by prism -e:1:in 'Kernel#sprintf': too many arguments for format string (ArgumentError) from -e:1:in '<main>' ``` ### Bug or Feature? I looked around the Ruby codebase, as far as I can tell this is the only method behaving this way (aside from its aliases like `String#%`). So I filed this as a Feature, but really in my opinion it is a bug. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125903] [Ruby Feature#22139] Prohibit `END{}`/`Kernel#at_exit` in non-main Ractor
by ko1 (Koichi Sasada) 09 Jul '26

09 Jul '26

Issue #22139 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22139: Prohibit `END{}`/`Kernel#at_exit` in non-main Ractor https://bugs.ruby-lang.org/issues/22139 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- Let's prohibit `END{}`/`Kernel#at_exit` on non-main Ractor. The current behavior is strange: ```ruby Ractor.new{ at_exit{ p [self, Ractor.current] } } sleep 1 #=> [#<Ractor:#2 t.rb:2 terminated>, #<Ractor:#1 running>] ``` There are some options: 1. prohibit them. Simple. 2. invoke the block at the end of the Ractor. 3. invoke the block at the end of the process on main Ractor. It is similar idea of the current behavior. 2 is rejected clearly by Matz because of the semantic gap with current behavior. 3 is no problem because the block and reachable objects from the block can be inherited to main Ractor. However, to make it simple, now let's prohibit them (1), and revisit if we found the (3) is needed. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123883] [Ruby Feature#21704] Expose rb_process_status_new to C extensions
by noteflakes (Sharon Rosner) 09 Jul '26

09 Jul '26

Issue #21704 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21704: Expose rb_process_status_new to C extensions https://bugs.ruby-lang.org/issues/21704 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_new` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:126019] [Ruby Feature#16757] Add intersection to Range
by matz (Yukihiro Matsumoto) 09 Jul '26

09 Jul '26

Issue #16757 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed Closing this issue. We have accepted `Range#clamp` (#22175), which covers the main use case here: restricting a range to given bounds. For overlapping ranges it gives the same result as an intersection would. I do not want to add a general `Range#intersection` (or `Range#&`). It raises semantic questions with no obviously right answer, such as what to return for disjoint ranges (`nil`, an empty range, or an exception). More fundamentally, it frames Range as a set-like collection, which invites `Range#union` next, and union of two ranges cannot be defined in general because the result may be discontiguous. I prefer to keep Range out of set algebra. Matz. ---------------------------------------- Feature #16757: Add intersection to Range https://bugs.ruby-lang.org/issues/16757#change-117998 * Author: stuyam (Stuart Yamartino) * Status: Closed ---------------------------------------- It would be great if there was a way to do an intersection with ranges. I wrote a method recently to solve this but it gets complicated and doesn't solve for all edge cases. The example I was using it for was getting the intersection of two date ranges. I was using it to calculate pricing discounts for overlapping dates for a reservation system. I would propose something like: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)) & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)) => Wed, 15 Apr 2020..Mon, 20 Apr 2020 ``` There are a handful of array methods that you can just convert a range to and do on an arrays rather than the ranges themselves, like so: ``` ruby (Date.new(2020, 04, 03)..Date.new(2020, 04, 20)).to_a & (Date.new(2020, 04, 15)..Date.new(2020, 04, 30)).to_a => [Wed, 15 Apr 2020, Thu, 16 Apr 2020, Fri, 17 Apr 2020, Sat, 18 Apr 2020, Sun, 19 Apr 2020, Mon, 20 Apr 2020] ``` There are a few issues with this however: 1. Performance: creating the ranges into arrays and doing array calculations can me slower based on the span of the range. 2. Returning a range: if you want to go back to a range, you need to convert the resulting array back to a range, which involves min and maxing the array and handling nil edge cases. 3. Infinite ranges: Now that there are endless and beginless ranges added in ruby 2.6 and 2.7 respectively, you can not convert an infinite range to an array and therefore can't do an intersection without more complex logic. I think the added infinite range support makes it a good reason to add range intersections since that is a feature you can't accomplish with just an array. It looks like there was an [Array#intersection alias](https://bugs.ruby-lang.org/issues/16155) added for Array#& recently. I would propose Range#& and Range#intersection to have parity with Array and Set methods. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125920] [Ruby Feature#22175] Add `Range#clamp`
by nobu (Nobuyoshi Nakada) 09 Jul '26

09 Jul '26

Issue #22175 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22175: Add `Range#clamp` https://bugs.ruby-lang.org/issues/22175 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I would like to propose `Range#clamp`, which returns a new `Range` whose begin and end values are clamped to the given bounds. Proposed call-seq: ```ruby range.clamp(min, max) -> range range.clamp(bounds) -> range ``` This is a range counterpart of `Comparable#clamp`. While `Comparable#clamp` clamps a single value, `Range#clamp` clamps both endpoints of a range. Examples: ```ruby (1..10).clamp(3, 7) #=> 3..7 (1...10).clamp(3, 7) #=> 3..7 (1...10).clamp(3, 10) #=> 3...10 (0...).clamp(0, 10) #=> 0..10 (1..10).clamp(3..7) #=> 3..7 (1..10).clamp(3...7) #=> 3...7 (1..5).clamp(3...7) #=> 3..5 ``` `clamp(min, max)` behaves like clamping by an inclusive range `min..max`. If an exclusive upper bound is needed, a range argument can be used: ```ruby (1..10).clamp(3...7) #=> 3...7 ``` Beginless and endless ranges are also supported: ```ruby (..10).clamp(3, 7) #=> 3..7 (0...).clamp(0, 10) #=> 0..10 (1..10).clamp(..7) #=> 1..7 (1..10).clamp(...7) #=> 1...7 (1..10).clamp(3..) #=> 3..10 ``` If the receiver is entirely outside the clamping bounds, the returned range is empty: ```ruby (1..10).clamp(20..30) #=> 20...20 (1..10).clamp(-10..0) #=> 0...0 (1..).clamp(..0) #=> 0...0 ``` The returned range excludes its end when the returned end value is an excluded end value of either the receiver or the argument range: ```ruby (1...10).clamp(3, 10) #=> 3...10 (1..10).clamp(3...10) #=> 3...10 ``` Otherwise, the returned range includes its end. #### Relation to [Feature #16757] [Feature #16757] proposes `Range#intersection` / `Range#&` as a general operation for intersecting two ranges. `Range#clamp` is closely related, but intentionally narrower. It treats the argument as clamping bounds for the receiver, similar to how `Comparable#clamp` treats its arguments as bounds for one value. For overlapping ranges, `range.clamp(bounds)` often produces the same result as a range intersection. For example: ```ruby (1..10).clamp(3..7) #=> 3..7 ``` However, `clamp` has a bounds-oriented API and naturally supports the two-argument form: ```ruby (1..10).clamp(3, 7) #=> 3..7 ``` Also, when the receiver is outside the bounds, `clamp` returns an empty `Range` at the nearest bound, rather than needing to decide whether a general intersection operation should return `nil`, `[]`, an empty range, or raise: ```ruby (1..10).clamp(20..30) #=> 20...20 ``` So this proposal can be considered either independently, as a range counterpart of `Comparable#clamp`, or as a smaller operation that could coexist with a future `Range#intersection`. #### Motivation It is common to restrict ranges to known boundaries, for example when limiting source locations, pagination windows, numeric domains, date/time windows, or user-provided ranges. Currently this has to be written manually by clamping both endpoints and reconstructing the range while preserving the correct excluded-end behavior. That logic is easy to get subtly wrong, especially with exclusive ranges, beginless/endless ranges, and ranges that become empty after clamping. `Range#clamp` would provide a small, direct API for this operation. #### Notes The method returns a new `Range` instance. The single-argument form accepts a range-like object accepted by Ruby’s range conversion logic. Source checked: [[Feature #16757]: Add intersection to Range](https://bugs.ruby-lang.org/issues/16757). -- https://bugs.ruby-lang.org/

5 7

[ruby-core:125953] [Ruby Feature#22185] Add alignment directives to `Array#pack` and `String#unpack`
by nobu (Nobuyoshi Nakada) 09 Jul '26

09 Jul '26

Issue #22185 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22185: Add alignment directives to `Array#pack` and `String#unpack` https://bugs.ruby-lang.org/issues/22185 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- `Array#pack` and `String#unpack` can express byte skips and absolute positions with `x`, `X`, and `@`, but they do not currently have a direct way to align the current position to a byte boundary or to the ABI alignment of another directive. This makes it awkward to describe binary formats that follow C-like structure layout rules. Users need to calculate padding manually, and the required padding can depend on the platform ABI. I propose adding alignment forms to pack templates. ### Alignment Directive ```ruby [1, 2].pack("C x!4 C") # => "\x01\x00\x00\x00\x02" ``` `x!N` advances to the next `N`-byte boundary, filling with NUL bytes when packing and skipping bytes when unpacking. The alignment can also be specified by another directive: ```ruby [1, 2].pack("C x!i i") ``` Here `x!i` aligns to the native alignment of the `i` directive. This lets templates describe platform-dependent native layouts without spelling out the padding size. ### Alignment Mode For formats that need repeated C-structure-style alignment, add an alignment mode: ```ruby [1, 2].pack("!{C i}") ``` This is equivalent to inserting the necessary alignment before each numeric or pointer directive, for example: ```ruby [1, 2].pack("C x!i i") ``` The alignment mode is intentionally not nested. ### Relative and Absolute Alignment There is also a distinction between relative and absolute alignment when `buffer:` or `offset:` is used. `x!` aligns relative to the starting position of the current pack/unpack operation, while `@!` aligns relative to the beginning of the output or input string: ```ruby buffer = +"z" [1, 2].pack("C x!4 C", buffer: buffer) buffer # => "z\x01\x00\x00\x00\x02" buffer = +"z" [1, 2].pack("C @!4 C", buffer: buffer) buffer # => "z\x01\x00\x00\x02" ``` Similarly for unpacking: ```ruby "z\x01\x00\x00\x00\x02".unpack("C x!4 C", offset: 1) # => [1, 2] "z\x01\x00\x00\x02".unpack("C @!4 C", offset: 1) # => [1, 2] ``` This keeps `x!` useful for templates that describe a sub-layout starting at the given `buffer:`/`offset:` position, while `@!` covers formats whose alignment is based on the absolute position in the whole binary string. ### Caveats The directive-alignment form rejects endian modifiers, since byte order does not affect ABI alignment. For example, `x!i` is meaningful, but `x!i<` should not be accepted as an alignment specifier. The alignment is for the pack/unpack offset, not a guarantee about the native address of the underlying String buffer. Callers that need to pass the buffer to C as a typed pointer must ensure separately that the actual address is suitably aligned. Shared substrings, for example, may start at an arbitrary byte offset. ### Examples A concrete use case is building or reading binary records whose layout is shared with C code. For example, a file format, IPC message, device command buffer, or FFI payload may contain records equivalent to: ```C struct entry { uint8_t tag; uint32_t size; void *data; }; ``` Today, a Ruby template has to spell out the padding manually: ```ruby [tag, size, data].pack("C xxx L J") ``` This is both error-prone and ABI-dependent. The padding after `tag` depends on the native alignment of `uint32_t`, and the next field may depend on pointer alignment. With alignment directives, the template can express the intended layout directly: ```ruby [tag, size, data].pack("!{C L J}") ``` or, when only one boundary is needed: ```ruby [tag, size].pack("C x!L L") ``` One target use case is binary buffers that contain several C-like record types. For example, an IPC or device buffer may store a sequence of records, each with its own layout. It is natural to pack or unpack each record with a separate template at a given `buffer:` or `offset:` position. In that case `x!` is useful for alignment relative to the start of the current record, while `@!` is useful for formats whose alignment is defined relative to the start of the whole buffer. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125756] [Ruby Bug#22112] Backport for IO::Buffer USF issues
by nagachika (Tomoyuki Chikanaga) 09 Jul '26

09 Jul '26

Issue #22112 has been reported by nagachika (Tomoyuki Chikanaga). ---------------------------------------- Bug #22112: Backport for IO::Buffer USF issues https://bugs.ruby-lang.org/issues/22112 * Author: nagachika (Tomoyuki Chikanaga) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The following commits are a series of fixes for IO::Buffer use-after-free issues across multiple methods. Please backport them to the stable branches. - commit:2552db04ddc44349c7b0f5f93aeb0fb02eccb509 (Fix UAF in IO::Buffer#&) - commit:95626e3a9c59cd073221c08ed013ed0f2d655b6f (Fix UAF in IO::Buffer#|) - commit:90ed85f91ed8c9df26efcbdc5e6a1b428be3ef06 (Fix UAF in IO::Buffer#^) - commit:3373fcc2dee7c4560d2c3e4280c549cdb1b5de63 (Fix UAF in IO::Buffer#~) - commit:4bd3e14fc2623414680008c7b1d38f1a3df2877e (Fix UAF in IO::Buffer#and!, IO::Buffer#or!, IO::Buffer#xor!) - commit:2c8002d58302e4fff51484826e1fd706cc2bfb19 (Validate the buffer after argument conversion) - commit:773e0c3a0f2ab2bd235c8d44cad1f999bfe2514b (Validate the buffer after type argument conversion) -- https://bugs.ruby-lang.org/

2 2