Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

src: allow getting Symbols on process.env #9631

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions src/node.cc
Original file line number Diff line number Diff line change
Expand Up @@ -2681,6 +2681,9 @@ static void ProcessTitleSetter(Local<Name> property,
static void EnvGetter(Local<Name> property,
const PropertyCallbackInfo<Value>& info) {
Isolate* isolate = info.GetIsolate();
if (property->IsSymbol()) {
return info.GetReturnValue().SetUndefined();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling .SetUndefined() explicitly doesn't hurt but it's not strictly necessary as it's the default return value. We don't call it anywhere else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bnoordhuis I think making the return value explicit is more readable here, that’s all. If you prefer, I have no problem dropping it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this the C++ equivalent of function() { return undefined; }? I've no strong feelings, but explicit isn't necessarily more readable, IMHO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this the C++ equivalent of function() { return undefined; }?

Yup.

I've no strong feelings, but explicit isn't necessarily more readable, IMHO.

I agree, but in this instance I think it makes sense.

}
#ifdef __POSIX__
node::Utf8Value key(isolate, property);
const char* val = getenv(*key);
Expand Down
9 changes: 5 additions & 4 deletions test/parallel/test-process-env-symbols.js
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,8 @@ const assert = require('assert');
const symbol = Symbol('sym');
const errRegExp = /^TypeError: Cannot convert a Symbol value to a string$/;

// Verify that getting via a symbol key throws.
assert.throws(() => {
process.env[symbol];
}, errRegExp);
// Verify that getting via a symbol key returns undefined.
assert.strictEqual(process.env[symbol], undefined);

// Verify that assigning via a symbol key throws.
assert.throws(() => {
Expand All @@ -24,3 +22,6 @@ assert.throws(() => {
assert.throws(() => {
symbol in process.env;
}, errRegExp);

// Checks that well-known symbols like `Symbol.toStringTag` won’t throw.
assert.doesNotThrow(() => Object.prototype.toString.call(process.env));
2 changes: 2 additions & 0 deletions test/parallel/test-util-inspect.js
Original file line number Diff line number Diff line change
Expand Up @@ -925,3 +925,5 @@ checkAlignment(new Map(big_array.map(function(y) { return [y, null]; })));
util.inspect.defaultOptions = 'bad';
}, /"options" must be an object/);
}

assert.doesNotThrow(() => util.inspect(process));