I measured this on Windows 11, and the problem does not occur there. I would like to withdraw this proposal. On Windows 11 (10.0.26300.9711, ucrtbase.dll 10.0.26100.9711), `memchr` in ucrtbase.dll is no longer a byte-by-byte loop. It ...watson1978 (Shizuo Fujita)
For desktop UCRT builds, mingw-w64 currently imports `memchr` rather than providing its own implementation. Its `libucrt.a` imports the function through `api-ms-win-crt-private-l1-1-0.dll`, which resolves to `ucrtbase.dll` on the tested ...watson1978 (Shizuo Fujita)
## Summary On x64-mingw-ucrt, `memchr` comes from `ucrtbase.dll`. On the tested system, it is a byte-by-byte loop and runs at about 2.5 GB/s, the same speed as a plain byte loop. Ruby calls `memchr` for single-byte searches, so `Strin...watson1978 (Shizuo Fujita)
## Description When a fiber scheduler cancels an offloaded blocking operation before a worker starts it, `rb_nogvl` returns normally even though the function never ran. It returns the zero-initialized result, so the caller cannot dist...watson1978 (Shizuo Fujita)
Looks like we are about to get yet another vendored implementation of the same kind: https://github.com/ohler55/oj/pull/1095 proposes vendoring the same Boost-licensed fpconv (Grisu2) code that the json gem already ships. I think it is...watson1978 (Shizuo Fujita)
On current master, two `Regexp` objects that have the same options, the same regexp encoding (`Regexp#encoding`), and byte-identical sources are no longer `==` if their *source strings* have different encodings (e.g. `ASCII-8BIT` vs `US...watson1978 (Shizuo Fujita)
Arch Linux provides GCC 15.2.1. https://archlinux.org/packages/core/x86_64/gcc/ When I build Ruby 3.4.6 with GCC 15.2.1, it cause error: ### How to Reproduce Here is a Dockerfile to reproduce the error: ``` FROM archlinux:lat...watson1978 (Shizuo Fujita)
We are running tests using Ruby HEAD on Linux, macOS, and Windows platforms. https://github.com/fluent/fluentd/actions/runs/17022072274 The SEGV are caused on each platforms...watson1978 (Shizuo Fujita)