Make process.env less weird

[isaacs]

The process.env object is a bit weird. It doesn't do prototypical inheritance at all, though its __proto__ member evaluates to an object. What's worse, it reports errors in these cases really strangely:

> process.env.toString()
TypeError: Property 'toString' of object #<error> is not a function
> process.env.xyz = function() { return 'xyz' }
[Function]
> process.env.xyz()
TypeError: Property 'xyz' of object #<error> is not a function

The historical reason for this is that process.env is actually a proxy object that calls getenv and setenv behind the scenes. This is important, because it provides a way to interact with addons that may be running in the same process (but not in the V8 runtime.) If they call setenv then the results should be visible on this object.

However, the EnvSetter and EnvGetter functions should treat __proto__ differently, and should use the Object.prototype as the prototype, so that process.env behaves more like a regular JavaScript object.

Also, whatever is causing that #<error> in the TypeError has got to go. It should report its [[Class]] value as object Environment or some such.

This cannot be done in Node v0.8, since it is a behavior change.

[piscisaureus]

@isaacs Had to revert because master was completely broken by it.

[bnoordhuis]

For the record, it was making node fail at startup.

#
# Fatal error in ../deps/v8/src/handles-inl.h, line 65
# CHECK(reinterpret_cast<Address>(*location_) != kHandleZapValue) failed
#

==29807== Process terminating with default action of signal 5 (SIGTRAP)
==29807==    at 0xC23C9D: v8::internal::OS::DebugBreak() (platform-linux.cc:389)
==29807==    by 0xC23C91: v8::internal::OS::Abort() (platform-linux.cc:371)
==29807==    by 0x8BA8CB: V8_Fatal (checks.cc:58)
==29807==    by 0x895B8F: v8::internal::Handle<v8::internal::Object>::operator*() const (handles-inl.h:65)
==29807==    by 0xA2FD27: v8::internal::JSObject::GetPropertyWithInterceptor(v8::internal::JSReceiver*, v8::internal::String*, PropertyAttributes*) (objects.cc:10290)
==29807==    by 0xA0DC3E: v8::internal::Object::GetProperty(v8::internal::Object*, v8::internal::LookupResult*, v8::internal::String*, PropertyAttributes*) (objects.cc:639)
==29807==    by 0xA0D59F: v8::internal::Object::GetProperty(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::LookupResult*, v8::internal::Handle<v8::internal::String>, PropertyAttributes*) (objects.cc:565)
==29807==    by 0xC4522A: v8::internal::LoadIC::Load(v8::internal::InlineCacheState, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::String>) (ic.cc:922)
==29807==    by 0xC4A4FA: v8::internal::LoadIC_Miss(v8::internal::Arguments, v8::internal::Isolate*) (ic.cc:2067)
==29807==    by 0x3F5DC580618D: ???

[isaacs]

Wow, that's weird. How do you get it to blow up like that?

[isaacs]

That is, is this a bug in V8's AccessorInfo stuff, or did I do something stupid like let the info->Data() get GC'd?

[bnoordhuis]

@isaacs Sorry, I forgot to close this issue again. I've re-applied your commit in fee02db. The problem was a missing scope.Close(...).