May 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113499] [Ruby master Feature#12165] Hash#first, Hash#last
by bughit (bug hit) 16 May '23

16 May '23

Issue #12165 has been updated by bughit (bug hit). @nobu Since you commented recently, what do you think about about a performant Hash#last(n=1) and a related performant Hash#reverse_each ? Should any ordered collection have those? ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103094 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113497] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 16 May '23

16 May '23

Issue #18743 has been updated by marcper (Marcelo Pereira). Hey again, @ko1. This is just a reminder that the patch is pushed to Github and is waiting for a decision. Best, Marcelo ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103093 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113494] [Ruby master Bug#11582] On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float
by ngoto (Naohisa Goto) 16 May '23

16 May '23

Issue #11582 has been updated by ngoto (Naohisa Goto). Status changed from Third Party's Issue to Closed This issue is solved by [Misc #15347]. In the C99 spec, The behavior of pow(3) in corner cases are clearly defined. Since Ruby 2.7, C99 is required to compile CRuby source code, and thus Ruby's pow method conforms to the C99 standard. ---------------------------------------- Bug #11582: On Solaris, Rational#** returns -Infinity for Rational(0) when passed a negative Float https://bugs.ruby-lang.org/issues/11582#change-103079 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- For instance, > Rational(0, 1) ** -1.0 => +Infinity on most platforms, -Infinity on Solaris by default. The Rational is implicitly converted to the Float value 0.0, and the libm function pow(0.0, -1.0) is called. Should this kind of behavior be made consistent by Ruby or should we accept this as dependent on the libm/libc used? They are likely other edges cases for pow() which might differ, and I think in general Ruby should try to unify these cases so the behavior is consistent across platforms at least for arithmetic. For more details, please see https://github.com/ruby/rubyspec/issues/134 reported by ngoto. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113492] Storage Notice: Your mailbox is full
by ruby-core＠ml.ruby-lang.org 15 May '23

15 May '23

1 0

[ruby-core:113288] [Ruby master Misc#19608] Being a co-maintainer of the ruby/openssl for the OpenSSL FIPS mode
by jaruga (Jun Aruga) 15 May '23

15 May '23

Issue #19608 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #19608: Being a co-maintainer of the ruby/openssl for the OpenSSL FIPS mode https://bugs.ruby-lang.org/issues/19608 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- ## Motivation and context Recently I have been working for the [ruby/openssl](https://github.com/ruby/openssl) to support OpenSSL 3 FIPS mode such as sending pull-requests and reporting issues to the [OpenSSL project](https://github.com/openssl/openssl). The related issue ticket is [here](https://github.com/ruby/openssl/issues/603). Currently a challenge of the ruby/openssl is that it doesn't work well on the OpenSSL FIPS mode, and I want ruby/openssl to work on it by adding the OpenSSL 3 FIPS mode case to the CI, and by adding more FIPS related unit tests and features. To solve this challenge, I would like to be a co-maintainer of the ruby/openssl for the FIPS mode related things. What do you think? ## What is FIPS mode? For someone who is interested in knowing the FIPS mode. Let me share the related documents below. In my understanding, FIPS mode is a security policy developed by US government. In some cases, the shipped Linux OS systems need to follow this policy. FIPS related documents: * [FIPS Wikipedia](https://en.wikipedia.org/wiki/Federal_Information_Processing_Sta… * [RHEL](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linu… * [Amazon Linux](https://aws.amazon.com/blogs/publicsector/enabling-fips-mode-amazon-… * [SUSE Linux](https://www.suse.com/support/kb/doc/?id=000019432) * [Ubuntu](https://ubuntu.com/security/certifications/docs/fips) And OpenSSL has a feature to enable the FIPS mode. The README is [here](https://github.com/openssl/openssl/blob/master/README-FIPS.md). And there can be FIPS specific issues in the ruby/openssl with the OpenSSL FIPS mode enabled. ## Past FIPS related issue tickets As a reference, I just found some old issue tickets below. It is about OpenSSL 1.0 and 1.1 FIPS mode. * https://bugs.ruby-lang.org/issues/6946 * https://bugs.ruby-lang.org/issues/19073 -- https://bugs.ruby-lang.org/

2 5

[ruby-core:113449] [Ruby master Bug#19635] errno may be overwritten by rb_sprintf if it triggers GC
by wks (Kunshan Wang) 15 May '23

15 May '23

Issue #19635 has been reported by wks (Kunshan Wang). ---------------------------------------- Bug #19635: errno may be overwritten by rb_sprintf if it triggers GC https://bugs.ruby-lang.org/issues/19635 * Author: wks (Kunshan Wang) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Here is an excerpt in the `trap` function in `signal.c` ``` c oldfunc = ruby_signal(sig, func); if (oldfunc == SIG_ERR) rb_sys_fail_str(rb_signo2signm(sig)); ``` `ruby_signal` tries to register a signal handling function. If it fails, it returns `SIG_ERR`, and `errno` is set to by `sigaction` to indicate the error. However, the snippet above calls `rb_signo2signm(sig)` before calling `rb_sys_fail_str`. `rb_signo2signm` allocates a Ruby heap object using `rb_sprintf`. The problem is, **if this `rb_sprintf` triggers GC**, the garbage collector may perform may complex operations, including executing `obj_free`, calling `mmap` to allocate more memory from the OS, etc. They **may overwrite the `errno`**. So if GC is triggered in the very unfortunate time, the caller of the `trap` function will receive an exception, but with the wrong reason. This may cause some tests, such as the `test_trap_uncatchable_#{sig}` test cases in `test_signal.rb`, to fail. There are similar use cases in `hash.c`, for example: ```c if (ret) rb_sys_fail_str(rb_sprintf("setenv(%s)", name)); ``` The good practice is always loading from `errno` immediately after calling functions that may set `errno`, such as `sigaction` and `setenv`. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113486] [Ruby master Feature#19641] Allow setting OpenSSL::SSL::SSLContext in Net::HTTP
by shouichi (Shouichi KAMIYA) 15 May '23

15 May '23

Issue #19641 has been reported by shouichi (Shouichi KAMIYA). ---------------------------------------- Feature #19641: Allow setting OpenSSL::SSL::SSLContext in Net::HTTP https://bugs.ruby-lang.org/issues/19641 * Author: shouichi (Shouichi KAMIYA) * Status: Open * Priority: Normal ---------------------------------------- [Abstract] Allow setting OpenSSL::SSL::SSLContext in Net::HTTP. [Background] The current implementation of Net::HTTP in Ruby allows setting certain properties of SSLContext, but not SSLContext itself. This limits the flexibility when communicating with servers that are not under our control, as we need to keep adding options to Net::HTTP every time someone wants to set properties that are not already supported. - https://bugs.ruby-lang.org/issues/9450 - https://bugs.ruby-lang.org/issues/9758 - https://bugs.ruby-lang.org/issues/16555 - https://bugs.ruby-lang.org/issues/18418 [Proposal] This proposal suggests allowing setting SSLContext itself to Net::HTTP, in addition to the current options. This would increase the flexibility and allow users to perform more complex SSL configurations. [Use cases] A user wants to set OpenSSL::SSL::Context#security_level which is not currently supported by the existing SSL options in Net::HTTP. [Discussion] This feature is necessary because it gives more flexibility to users who need to communicate with servers that require custom SSL configurations. It is better than using existing features because it allows users to set up SSL configurations that are not currently supported by the existing options, and it can potentially simplify the API by allowing users to set SSLContext itself instead of having to provide multiple options for every possible SSL configuration. A potential drawback is conflict handling may not be obvious to users. For example, what happens if a user both sets Net::HTTP#verify_hostname and OpenSSL::SSL::Context#verify_hostname? [See also] Python allows users to pass context to HTTPSConnection and key_file and cert_file options are deprecated in favor of context. https://docs.python.org/3/library/http.client.html#http.client.HTTPSConnect… -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111566] [Ruby master Bug#19294] Enumerator.product works incorrectly with consuming enumerators
by zverok (Victor Shepelev) 14 May '23

14 May '23

Issue #19294 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19294: Enumerator.product works incorrectly with consuming enumerators https://bugs.ruby-lang.org/issues/19294 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby s = StringIO.new('abc') Enumerator.product([1, 2, 3], s.each_char).to_a # Expected: => [[1, "a"], [1, "b"], [1, "c"], [2, "a"], [2, "b"], [2, "c"], [3, "a"], [3, "b"], [3, "c"]] # Actual: => [[1, "a"], [1, "b"], [1, "c"]] ``` The implementation consumes the non-first enumerator to produce the first combination. Somewhat related to the dilemma of consuming and non-consuming enumerators (#19061). PS: I noticed I don't understand why it is `Enumerator.product` and not `Enumerable#product`, but probably it is too late to raise the questions :( -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113420] [Ruby master Bug#19632] Disable external iterator for frozen enumerator
by make_now_just (Hiroya Fujinami) 14 May '23

14 May '23

Issue #19632 has been reported by make_now_just (Hiroya Fujinami). ---------------------------------------- Bug #19632: Disable external iterator for frozen enumerator https://bugs.ruby-lang.org/issues/19632 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Currently, methods to manipulate an external iterator like `#next` and `#feed` can be called even if a receiver of an enumerator is frozen. However, these methods change the state of an external iterator in an enumerator. Therefore, it seems a BUG to me, and these methods should raise FrozenError if the receiver is frozen. ```ruby e = 3.times.freeze # Current e.next # => 1 e.next # => 2 # Expected e.next # raise FrozenError ``` Two years ago, this issue was mentioned in [a comment](https://bugs.ruby-lang.org/issues/17195#note-5). I suggest fixing the following methods to raise FrozenError against a frozen enumerator. - `Enumerator#next` - `Enumerator#next_values` - `Enumerator#peek` - `Enumerator#peek_values` - `Enumerator#feed` - `Enumerator#rewind` Also, even if an enumerator is frozen, it does not affect other methods for internal iterators. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:113477] [Ruby master Bug#19639] Escaped newline literals in Regexp are ignored in extended / free-spacing mode
by janosch-x 14 May '23

14 May '23

Issue #19639 has been reported by janosch-x (Janosch Müller). ---------------------------------------- Bug #19639: Escaped newline literals in Regexp are ignored in extended / free-spacing mode https://bugs.ruby-lang.org/issues/19639 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin21] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When we want to match whitespace with a Regexp that uses the x-flag, we can do that with escaped literal whitespace: ```ruby ' '[/\ /x] # => " " ``` This works for all whitespace - except newlines: ```ruby "\n"[/\ /x] # => "" /\ /x.source # => "" ``` I guess another parsing step eliminates such escaped newlines before the regexp parsing happens? It is probably a rare issue because most people prefer "\n" in Regexps over literal newlines, but at least the relevant statement in the [documentation](https://docs.ruby-lang.org/en/master/regexp_rdoc.html#label-… is a bit too broad as it is: > Use escaped whitespace such as \ , i.e. a space preceded by a backslash. Maybe we want to add a caveat like `(Does not work for newlines.)`? -- https://bugs.ruby-lang.org/

2 1