From: merch-redmine@... Date: 2019-06-15T17:31:03+00:00 Subject: [ruby-core:93164] [Ruby trunk Bug#15920] Check frozen state of ENV Issue #15920 has been updated by jeremyevans0 (Jeremy Evans). Eregon (Benoit Daloze) wrote: > One potential concern here is that even if `ENV` is frozen, C extensions, or native libraries linked by C extensions, might still call e.g., `setenv()` and effectively modify values returned by `ENV` (and even add new environment variables). C extensions and natively libraries can modify frozen Ruby objects (even unfreeze objects), so I don't see the how `ENV` is special. > Raising on `freeze` seems uncommon, but it might make sense here since there is not real way to completely freeze `ENV`. My preference would be to support `ENV.freeze`, and disallow modifications to `ENV` afterward, but I'm fine with `ENV.freeze` raising. I think the current behavior in this area is a bug, though. ---------------------------------------- Bug #15920: Check frozen state of ENV https://bugs.ruby-lang.org/issues/15920#change-78605 * Author: kachick (Kenichi Kamiya) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- github: https://github.com/ruby/ruby/pull/2234 Is this an intentional behavior? ``` ruby ENV.freeze ENV.clear #=> No exception happen ``` raising FronzenError sounds reasonable to me ---Files-------------------------------- env-frozen.patch (3.9 KB) env-no-freeze.patch (1.78 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: