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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>