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

[ruby-core:113501] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nobu (Nobuyoshi Nakada) 17 May '23

17 May '23

Issue #18743 has been updated by nobu (Nobuyoshi Nakada). Seems find to me. One thing I concerned, `stop_exc` will be re-created every times, and no way to know where it was first used up. How about chaining by `cause`? ```diff diff --git a/enumerator.c b/enumerator.c index b33c1713718..1cc8f9108cf 100644 --- a/enumerator.c +++ b/enumerator.c @@ -30,6 +30,9 @@ #include "internal/rational.h" #include "ruby/ruby.h" +extern ID ruby_static_id_cause; +#define id_cause ruby_static_id_cause + /* * Document-class: Enumerator * @@ -787,8 +790,16 @@ get_next_values(VALUE obj, struct enumerator *e) { VALUE curr, vs; - if (e->stop_exc) - rb_exc_raise(e->stop_exc); + if (e->stop_exc) { + VALUE exc = e->stop_exc; + VALUE result = rb_attr_get(exc, id_result); + VALUE mesg = rb_attr_get(exc, idMesg); + if (!NIL_P(mesg)) mesg = rb_str_dup(mesg); + VALUE stop_exc = rb_exc_new_str(rb_eStopIteration, mesg); + rb_ivar_set(stop_exc, id_result, result); + rb_ivar_set(stop_exc, id_cause, exc); + rb_exc_raise(stop_exc); + } curr = rb_fiber_current(); ``` In the test, save `$!` at the first `rescue` then `assert_same(cause, exc.cause)`. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103096 * 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:113500] [Ruby master Feature#12165] Hash#first, Hash#last
by nobu (Nobuyoshi Nakada) 17 May '23

17 May '23

Issue #12165 has been updated by nobu (Nobuyoshi Nakada). Although I've not thought about `Hash#last`, once when `st_table` got keeping the insertion order I proposed `Hash#reverse_each` (`st_reverse_foreach` for it precisely) to matz, but was rejected. ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-103095 * 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: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