December 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:120313] [Ruby master Bug#20967] Oracle Developer Studio 12.5 on Solaris 10 miniruby symbol referencing error: Undefined symbol: atomic_signal_fence
by ngoto (Naohisa Goto) 18 Dec '24

18 Dec '24

Issue #20967 has been reported by ngoto (Naohisa Goto). ---------------------------------------- Bug #20967: Oracle Developer Studio 12.5 on Solaris 10 miniruby symbol referencing error: Undefined symbol: atomic_signal_fence https://bugs.ruby-lang.org/issues/20967 * Author: ngoto (Naohisa Goto) * Status: Open * Assignee: ngoto (Naohisa Goto) * ruby -v: ruby 3.3.5 (2024-11-05 revision 664bbbd0fd) [sparc64-solaris2.10] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When compiling Ruby 3.3 or head by using Oracle Developer Studio 12.5 on Solaris 10, failed to make miniruby with the following error messages: ``` Undefined first referenced symbol in file atomic_signal_fence vm.o ld: fatal: symbol referencing errors. No output written to miniruby make: *** [miniruby] Error 2 ``` Ruby 3.3.4 or later may be affected. This error occurred because of improper selection of atomic library in Oracle Developer Studio. https://docs.oracle.com/cd/E77782_01/html/E77789/gqhbq.html Adding `cflags` to `-xatomic=studio` or `-xatomic=gcc` when running `./configure` solved the problem. For example, ``` ./configure --prefix=/opt/ruby340 cflags="-xatomic=gcc" ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120304] [Ruby master Bug#20966] Unary
by getajobmike (Mike Perham) 18 Dec '24

18 Dec '24

Issue #20966 has been reported by getajobmike (Mike Perham). ---------------------------------------- Bug #20966: Unary https://bugs.ruby-lang.org/issues/20966 * Author: getajobmike (Mike Perham) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- /Users/mperham/src/sidekiq/test/profiling_test.rb:49: warning: literal string will be frozen in the future (run with --debug-frozen-string-literal for more information) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120300] [Ruby master Bug#20964] Oracle Developer Studio 12.5 on Solaris failed to compile "prism/extension.c", line 499: internal compiler error: Wasted space
by ngoto (Naohisa Goto) 18 Dec '24

18 Dec '24

Issue #20964 has been reported by ngoto (Naohisa Goto). ---------------------------------------- Bug #20964: Oracle Developer Studio 12.5 on Solaris failed to compile "prism/extension.c", line 499: internal compiler error: Wasted space https://bugs.ruby-lang.org/issues/20964 * Author: ngoto (Naohisa Goto) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Oracle Developer Studio 12.5 and 12.6 on Solaris 10 failed to compile prism/extension.c with the following error: ``` cc -errtags=yes -xO4 -xtarget=sparc64xplus -m64 -xatomic=gcc -g -erroff=E_STATEMENT_NOT_REACHED -erroff=E_INIT_SIGN_EXTEND -erroff=E_INIT_DOES_NOT_FIT -erroff=E_INITIALIZATION_TYPE_MISMATCH -DRUBY_EXPORT -I. -I.ext/include/sparc64-solaris2.10 -I../ruby.devel/include -I../ruby.devel -I../ruby.devel/prism -I../ruby.devel/enc/unicode/15.0.0 -D_XOPEN_SOURCE=600 -I/usr/local/64/lib/libffi-3.0.10/include -I/usr/local/64/include -o prism/extension.o -c ../ruby.devel/prism/extension.c "../ruby.devel/prism/extension.c", line 499: internal compiler error: Wasted space cc: acomp failed for ../ruby.devel/prism/extension.c make: *** [prism/extension.o] Error 2 ``` The line 499 in prism/extension.c is located at the end of parser_errors() function. It seems that the error message `internal compiler error: Wasted space` strongly suggests the compiler's bug. Changing optimization level did not solve the error. After some trial and error, I found that the following patch dismisses the error. ``` --- a/prism/extension.c +++ b/prism/extension.c @@ -464,11 +464,11 @@ parser_errors(pm_parser_t *parser, rb_encoding *encoding, VALUE source) { pm_diagnostic_t *error; for (error = (pm_diagnostic_t *) parser->error_list.head; error != NULL; error = (pm_diagnostic_t *) error->node.next) { - VALUE location_argv[] = { - source, - LONG2FIX(error->location.start - parser->start), - LONG2FIX(error->location.end - error->location.start) - }; + VALUE location_argv[3]; + + location_argv[0] = source; + location_argv[1] = LONG2FIX(error->location.start - parser->start); + location_argv[2] = LONG2FIX(error->location.end - error->location.start); VALUE level = Qnil; switch (error->level) { @@ -485,12 +485,12 @@ parser_errors(pm_parser_t *parser, rb_encoding *encoding, VALUE source) { rb_raise(rb_eRuntimeError, "Unknown level: %" PRIu8, error->level); } - VALUE error_argv[] = { - ID2SYM(rb_intern(pm_diagnostic_id_human(error->diag_id))), - rb_enc_str_new_cstr(error->message, encoding), - rb_class_new_instance(3, location_argv, rb_cPrismLocation), - level - }; + VALUE error_argv[4]; + + error_argv[0] = ID2SYM(rb_intern(pm_diagnostic_id_human(error->diag_id))); + error_argv[1] = rb_enc_str_new_cstr(error->message, encoding); + error_argv[2] = rb_class_new_instance(3, location_argv, rb_cPrismLocation); + error_argv[3] = level; rb_ary_push(errors, rb_class_new_instance(4, error_argv, rb_cPrismParseError)); } @@ -507,11 +507,11 @@ parser_warnings(pm_parser_t *parser, rb_encoding *encoding, VALUE source) { pm_diagnostic_t *warning; for (warning = (pm_diagnostic_t *) parser->warning_list.head; warning != NULL; warning = (pm_diagnostic_t *) warning->node.next) { - VALUE location_argv[] = { - source, - LONG2FIX(warning->location.start - parser->start), - LONG2FIX(warning->location.end - warning->location.start) - }; + VALUE location_argv[3]; + + location_argv[0] = source; + location_argv[1] = LONG2FIX(warning->location.start - parser->start); + location_argv[2] = LONG2FIX(warning->location.end - warning->location.start); VALUE level = Qnil; switch (warning->level) { @@ -525,12 +525,12 @@ parser_warnings(pm_parser_t *parser, rb_encoding *encoding, VALUE source) { rb_raise(rb_eRuntimeError, "Unknown level: %" PRIu8, warning->level); } - VALUE warning_argv[] = { - ID2SYM(rb_intern(pm_diagnostic_id_human(warning->diag_id))), - rb_enc_str_new_cstr(warning->message, encoding), - rb_class_new_instance(3, location_argv, rb_cPrismLocation), - level - }; + VALUE warning_argv[4]; + + warning_argv[0] = ID2SYM(rb_intern(pm_diagnostic_id_human(warning->diag_id))); + warning_argv[1] = rb_enc_str_new_cstr(warning->message, encoding); + warning_argv[2] = rb_class_new_instance(3, location_argv, rb_cPrismLocation); + warning_argv[3] = level; rb_ary_push(warnings, rb_class_new_instance(4, warning_argv, rb_cPrismParseWarning)); } ``` However, I don't like to add the patch because this change significantly decreases maintainability of code. I also think that the compiler's bug should be fixed in the compiler side and such dirty workaround should not be included. P.S. GCC 7.5.0 on Solaris 10 can compile the original code (without the workaround patch) with no errors. Therefore, it seems that this is not Solaris OS problem but the problem of Oracle Developer Studio 12.5/12.6 compiler. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:119883] [Ruby master Feature#20885] String#gsub?
by Dan0042 (Daniel DeLorme) 18 Dec '24

18 Dec '24

Issue #20885 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20885: String#gsub? https://bugs.ruby-lang.org/issues/20885 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- I would like a variation of sub/gsub that returns a new string if there is a match, or nil otherwise. This can be currently done with `str.dup.gsub!(...)` at the mere cost of 2 unnecessary extra allocations due to String#dup TBH I'm not sure we need yet another gsub method, but what gets me here is that `gsub?` is the primitive operation from which `gsub` and `gsub!` are made. Internally, these two methods work like this: ```ruby def gsub!(...) modified = gsub?(...) and replace(modified) end def gsub(...) gsub?(...) or dup end ``` We can efficiently derive these two methods from `gsub?`, but we cannot efficiently implement `gsub?` in ruby, so it feels regrettable to me that `gsub?` is not available as a built-in. Use cases include: ```ruby #ensure gsub has modified the string newstr = str.gsub?(rx,repl) or raise "str did not contain expected value" #take an action if the string is modified if str = obj.title.gsub?(rx,repl) obj.title = str obj.save end ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120299] [Ruby master Bug#20963] compile error due to lack of MAYBE_UNUSED macro e.g. Oracle Developer Studio 12.x on Solaris 10
by ngoto (Naohisa Goto) 18 Dec '24

18 Dec '24

Issue #20963 has been reported by ngoto (Naohisa Goto). ---------------------------------------- Bug #20963: compile error due to lack of MAYBE_UNUSED macro e.g. Oracle Developer Studio 12.x on Solaris 10 https://bugs.ruby-lang.org/issues/20963 * Author: ngoto (Naohisa Goto) * Status: Open * Assignee: ngoto (Naohisa Goto) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- On Solaris 10, by using Oracle Developer Studio 12.5, strange compile error occurred. ``` cc -errtags=yes -xO4 -xtarget=sparc64xplus -m64 -g -erroff=E_STATEMENT_NOT_REACHED -erroff=E_INIT_SIGN_EXTEND -erroff=E_INIT_DOES_NOT_FIT -erroff=E_INITIALIZATION_TYPE_MISMATCH -DRUBY_EXPORT -I. -I.ext/include/sparc64-solaris2.10 -I../ruby.devel/include -I../ruby.devel -I../ruby.devel/prism -I../ruby.devel/enc/unicode/15.0.0 -D_XOPEN_SOURCE=600 -I/usr/local/64/lib/libffi-3.0.10/include -I/usr/local/64/include -o main.o -c ../ruby.devel/main.c "../ruby.devel/include/ruby/internal/value.h", line 128: only "register" valid as formal parameter storage class "../ruby.devel/include/ruby/internal/value.h", line 128: warning: old-style declaration or incorrect type for: MAYBE_UNUSED (E_OLD_STYLE_DECL_OR_BAD_TYPE) "../ruby.devel/include/ruby/internal/value.h", line 129: only "register" valid as formal parameter storage class "../ruby.devel/include/ruby/internal/value.h", line 129: warning: old-style declaration or incorrect type for: MAYBE_UNUSED (E_OLD_STYLE_DECL_OR_BAD_TYPE) "../ruby.devel/include/ruby/internal/value.h", line 130: only "register" valid as formal parameter storage class "../ruby.devel/include/ruby/internal/value.h", line 130: warning: old-style declaration or incorrect type for: MAYBE_UNUSED (E_OLD_STYLE_DECL_OR_BAD_TYPE) "../ruby.devel/include/ruby/internal/value.h", line 131: only "register" valid as formal parameter storage class "../ruby.devel/include/ruby/internal/value.h", line 131: warning: old-style declaration or incorrect type for: MAYBE_UNUSED (E_OLD_STYLE_DECL_OR_BAD_TYPE) cc: acomp failed for ../ruby.devel/main.c make: *** [main.o] Error 2 ``` In include/ruby/internal/static_assert.h, MAYBE_UNUSED is used without considering the possibility that it may not be defined. The macro MAYBE_UNUSED is defined in config.h after checking existence of `__unused__` attribute by ./configure, but the attribute is only available in GCC or GCC-like compilers. The following patch resolves the issue. I think it is good to use `RBIMPL_ATTR_MAYBE_UNUSED()` macro which is defined in ruby/internal/attr/maybe_unused.h. ``` --- a/include/ruby/internal/static_assert.h +++ b/include/ruby/internal/static_assert.h @@ -23,6 +23,7 @@ #include <assert.h> #include "ruby/internal/has/extension.h" #include "ruby/internal/compiler_since.h" +#include "ruby/internal/attr/maybe_unused.h" /** @cond INTERNAL_MACRO */ #if defined(__cplusplus) && defined(__cpp_static_assert) @@ -71,7 +72,7 @@ #else # define RBIMPL_STATIC_ASSERT(name, expr) \ - MAYBE_UNUSED(typedef int static_assert_ ## name ## _check[1 - 2 * !(expr)]) + RBIMPL_ATTR_MAYBE_UNUSED() typedef int static_assert_ ## name ## _check[1 - 2 * !(expr)] #endif #endif /* RBIMPL_STATIC_ASSERT_H */ ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120297] [Ruby master Bug#20962] Change in behaviour in 3.4.0rc1 of `Hash#inspect`
by aharan (Aidan Haran) 18 Dec '24

18 Dec '24

Issue #20962 has been reported by aharan (Aidan Haran). ---------------------------------------- Bug #20962: Change in behaviour in 3.4.0rc1 of `Hash#inspect` https://bugs.ruby-lang.org/issues/20962 * Author: aharan (Aidan Haran) * Status: Open * ruby -v: ruby 3.4.0rc1 (2024-12-12 master 29caae9991) +PRISM [aarch64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The output from `Hash#inspect` in v3.4.0rc1 does not match the documentation and is different from v3.3.6. <pre> # ruby -v ruby 3.4.0rc1 (2024-12-12 master 29caae9991) +PRISM [aarch64-linux] # irb irb(main):001> h = {foo: 0, bar: 1, baz: 2} => {foo: 0, bar: 1, baz: 2} irb(main):002> h.inspect => "{foo: 0, bar: 1, baz: 2}" irb(main):003> </pre> The documentation says that the output should be @"{:foo=>0, :bar=>1, :baz=>2}"@ https://github.com/ruby/ruby/blob/707c6420b1ea599c223a17781185c0b6fb0f3518/… In Ruby v3.3.6 the output is: <pre> # ruby -v ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [aarch64-linux] # irb irb(main):001> h = {foo: 0, bar: 1, baz: 2} => {:foo=>0, :bar=>1, :baz=>2} irb(main):002> h.inspect => "{:foo=>0, :bar=>1, :baz=>2}" </pre> -- https://bugs.ruby-lang.org/

2 1

[ruby-core:118957] [Ruby master Bug#20699] On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well
by flatland001 (Hayato Arai) 18 Dec '24

18 Dec '24

Issue #20699 has been reported by flatland001 (Hayato Arai). ---------------------------------------- Bug #20699: On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well https://bugs.ruby-lang.org/issues/20699 * Author: flatland001 (Hayato Arai) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In paths containing Japanese characters, such as: C:\テスト_test\test.rb Code: ``` ruby # this code -> C:\テスト_test\test.rb # external file -> C:\テスト_test\lib\foo.rb p __dir__ p __dir__.encoding p File.dirname(File.expand_path(__FILE__)) p File.dirname(File.expand_path(__FILE__)).encoding print "__dir__ == File.dirname(File.expand_path(__FILE__)): " p __dir__ == File.dirname(File.expand_path(__FILE__)) begin require_relative "lib/foo" puts "foo.rb loaded" rescue LoadError puts "LoadError: #{$!}" end ``` Results: ``` "C:/?e?X?g_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): false LoadError: cannot load such file -- C:/?e?X?g_test/lib/foo ``` However, in ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt], the same code produces the following expected results: ``` "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): true foo.rb loaded ``` Is this behavior expected, or could this be a bug in the Ruby interpreter on Windows? If this is my misunderstanding or a known issue, I apologize. Thank you for your consideration. Environment Information: - OS: Windows 11 Pro 23H2 (OS build 22631.4037) - Installed via: RubyInstaller - Shell: Command Prompt - File System: NTFS - System Locale: Japanese (Japan), Language: Japanese -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119380] [Ruby master Misc#20774] Remove remaining locale dependent code from Windows port
by larskanis (Lars Kanis) 18 Dec '24

18 Dec '24

Issue #20774 has been reported by larskanis (Lars Kanis). ---------------------------------------- Misc #20774: Remove remaining locale dependent code from Windows port https://bugs.ruby-lang.org/issues/20774 * Author: larskanis (Lars Kanis) * Status: Open ---------------------------------------- The external_encoding of files, file names and ENV on Windows were changed from locale codepage to UTF-8 in ruby-3.0. But there are still several remaining points where locale encoding is used although there is no need to do so. The Windows port is already fully UTF-16/UTF-8 based and locale encoding is only used for historical and not for technical reasons. My proposal is to remove (most of) the locale dependent conversions from the ruby code for Windows. Before I open pull requests in this regard, I would like to confirm this direction with the ruby core team. Let me show what I mean: ``` # täst-locale-enc.rb def pr(*strs) strs.each do |str| p [str, IO===str ? str.external_encoding&.name : str.encoding.name] end end if $0==__FILE__ pr STDIN # => [#<IO:<STDIN>>, "CP850"] pr $0 # => ["ruby/t\x84st-locale-enc.rb", "CP850"] pr __FILE__ # => ["ruby/t\x84st-locale-enc.rb", "CP850"] pr __dir__ # => ["C:/Users/kanis/ruby", "CP850"] pr 'ä' # => ["ä", "UTF-8"] pr '€' # => ["€", "UTF-8"] pr $:.first # => ["C:/Users/kanis/t\xE2\x82\xACst", "ASCII-8BIT"] pr $:.last # => ["C:/Ruby33-x64/lib/ruby/3.3.0/x64-mingw-ucrt", "CP850"] require "win32/registry" pr Win32::Registry::HKEY_CURRENT_USER.open("Environment")['TMP'] # => ["C:\\Users\\kanis\\AppData\\Local\\Temp", "UTF-8"] pr Win32::Registry::HKEY_CURRENT_USER.open("\\").each_key{ break _1 } # => ["AppEvents", "CP850"] end # execute with: ruby -It€st ruby\täst-locale-enc.rb ``` I wrote the results on `ruby-3.3 x64-mingw-ucrt` right into the code. The situation is even worse when called with `-e` script: ``` $ ruby -It€st -r .\ruby\täst-locale-enc.rb -e "pr STDIN, $0, __FILE__, __dir__, 'ä', '€', $:.first, $:.last" [#<IO:<STDIN>>, "CP850"] ["-e", "CP850"] ["-e", "UTF-8"] [".", "US-ASCII"] ["\x84", "CP850"] ["?", "CP850"] ["C:/Users/kanis/t\xE2\x82\xACst", "ASCII-8BIT"] ["C:/Ruby33-x64/lib/ruby/3.3.0/x64-mingw-ucrt", "CP850"] ``` There are also some inconsistencies like that it's possible to `require` script names with characters outside of the codepage, but it fails to execute a script directly or by using `require_relative` : ``` $ ruby -r .\t€st-locale-enc.rb -e "pr STDIN" [#<IO:<STDIN>>, "CP850"] $ ruby .\t€st-locale-enc.rb ruby: Invalid argument -- ./t?st-locale-enc.rb (LoadError) ``` Maybe there are more places which are working with locale codepage - these are only the few that I remember from memory. I would like to change all the above results to be UTF-8 encoded, like it is the case on Ubuntu. Compatibility ------------- Changing the encoding of returned strings is of course an API change. IMHO it is still something we should change in a minor release of ruby. The reason is that I don't remember about only a single issue cased by the change to UTF-8 in ruby-3.0 in the company I work for. To the contrary many issues are caused by using locale codepage where some non-ASCII characters work and other characters don't. Most issue with ruby-3.0 were cased by the keyword argument changes. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:120280] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by deivid 17 Dec '24

17 Dec '24

Issue #6648 has been updated by deivid (David Rodríguez). > But anyway, I was talking specifically about your Bundler example; I didn't see the point of -C in that specific example. Bundler executes right from the start; there's no opportunity for "user code" to change to a different directory, is there? The entrypoint to Bundler is not only the `bundle` CLI, but also a `require` of `bundler/setup`, for example. And sometimes stuff happens before that. But you're right that my example was not directly related to `-C`. Overall I don't think whether `-C` is included or not will affect Bundler, because of how little usage `-C` seems to have but it still feels better to me to include it since after all, it's part of the original argv. If `Process.argv` does not need it or wants to ignore it, that can be done manually. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-111046 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120277] [Ruby master Bug#20958] fix ENV.keys encoding on windows
by YO4 (Yoshinao Muramatsu) 17 Dec '24

17 Dec '24

Issue #20958 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #20958: fix ENV.keys encoding on windows https://bugs.ruby-lang.org/issues/20958 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- [github PR#12368](https://github.com/ruby/ruby/pull/12368) ENV.keys elements contain UTF-8 byte sequences with locale encoding on Windows. ``` > ruby -v -e "p ENV.keys.last; p ENV.keys.last.encoding; p ENV.keys.last.dup.force_encoding('utf-8')" ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x64-mingw-ucrt] "\x{E383}\x{86E3}\x{82B9}\x{E383}\x88" #<Encoding:Windows-31J> "テスト" ``` This patch changes the encoding of ENV.keys to utf-8 on Windows. -- https://bugs.ruby-lang.org/

1 0