Repository navigation
Conversation
| if (Array.isArray(args)) { | ||
| args = args.slice(0); | ||
| for (var i = 0; i < args.length; i++) | ||
| args[i] = `${args[i]}`; |
There was a problem hiding this comment.
Why not just args[i] += ''; ?
There was a problem hiding this comment.
That calls args[i][Symbol.toPrimitive]() (if there is one) with 'default' instead of 'string', thus breaking compatibility.
How are they semver-minor? Are there observable differences in behavior? |
They can be. For |
|
hmm... that may qualify as a semver-major depending on the context. Do you have some examples of where that would impact? |
| args[3]->IsObject()); | ||
| CHECK(args[4]->IsFunction()); | ||
| Utf8Value input(env->isolate(), args[0]); | ||
| CHECK(!input.IsInvalidated()); |
There was a problem hiding this comment.
If you remove the CHECK(args[0]->IsString()); (which I agree makes sense), can this be turned into just returning instead of crashing?
ditto for the remainder of the file (or am I missing something here?)
There was a problem hiding this comment.
I'll return in this and some other cases, but there are instances where Utf8Value is used where either returning is inconvenient (because it is an ordinary C++ method, not a V8 binding one) or technically impossible (there is an IsString() guard before attempting to read it through Utf8Value).
| if (!js_value->IsArray()) | ||
| return UV_EINVAL; | ||
|
|
||
| CHECK(js_value->IsArray()); |
There was a problem hiding this comment.
Are these changes related? Why is crashing better here? I think this one might be semver-major if it’s kept this way (or are there type checks somewhere else? In that case, could ParseStdioOptions be made more specific so it takes a Local<Array> instead?)
There was a problem hiding this comment.
Yes, before this PR, js_value might be not an array since it is not sanitized in JS. After this PR, they should be sanitized and it would be a bug if it is not an array here.
Somewhat; js_value should already have been sanitized in JS, and the return UV_EINVAL; is dead code.
|
ping @TimothyGu |
|
Looks like this has stalled out a bit. (Also needs a rebase.) Should we add a |
|
I'll close this for now. I can think of a better way of fixing this. |
So far all of the changes are semver-patch. Plans to replace certain usage of
Utf8ValuewithBufferValueare semver-minor and have not been done yet.cares_wrap.ccenv.ccnode.ccnode_buffer.ccnode_crypto.ccnode_dtrace.ccnode_file.ccnode_i18n.ccnode_lttng.ccnode_stat_watcher.ccnode_url.ccpipe_wrap.ccprocess_wrap.cctcp_wrap.cctls_wrap.ccudp_wrap.ccFixes: #9819
Fixes: #9820
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
src