From: eregontp@... Date: 2019-06-16T10:45:43+00:00 Subject: [ruby-core:93178] [Ruby trunk Bug#15920] Check frozen state of ENV Issue #15920 has been updated by Eregon (Benoit Daloze). jeremyevans0 (Jeremy Evans) wrote: > 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. I would call that entirely unsupported, and if there are ways to detect this, we should probably raise an exception. Basically, I believe it's undefined behavior to unfreeze an object or to change its internals. Doing that breaks the most fundamental guarantee of `Kernel#freeze`, i.e., that the object is immutable and therefore free from data races. OTOH, calling setenv() in a native library is fairly well-defined and there is nothing we can do to prevent that. `ENV` is special because it's basically just a wrapper of `environ`, and we can't control if that gets modified. Freezing `ENV` cannot be done reliably, so I believe it should `raise` and not pretend it's frozen when it's not. ---------------------------------------- Bug #15920: Check frozen state of ENV https://bugs.ruby-lang.org/issues/15920#change-78619 * 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: