assert: Check typed array view type in deepEqual #5910
Conversation
|
LGTM for both fixes. |
|
If the only concerning value is -0, this can be checked by if (a === 0 && b === 0)
if (a === 1/-0) return b === 1/-0;
else b !== 1/-0;Think that's it, but you get the idea. |
|
@trevnorris Not 100 % sure what you’re saying here. Yes, that is how you check for -0 vs +0, but:
Also, I’d assume checking each member of the typed arrays individually would defeat the whole purpose of speeding things up by comparing the underlying |
|
Don’t know whether you had a look at #5907, but maybe writing the problem with the current code down helps a bit: Right now, when both So, this patch changes the following things:
Let me know if this cleared things up a bit, and if so, what parts of it you would like to see included in the commit message. 😄 |
|
Ah. Misread your comment. Thought you wanted to. As for the only thing affected by bit-pattern. var dv1 = new DataView(new ArrayBuffer(8));
var dv2 = new DataView(new ArrayBuffer(8));
dv1.setFloat64(0, NaN); // bytes: 7f fc 0 0 0 0 0 0
// write sNaN
dv1.writeUint8(1, 0xfc);
dv2.writeFloat64(0, dv1.getFloat64(0)); // bytes: 7f fc 0 0 0 0 0 0Now notice how the same doesn't hold true for dv1.setFloat64(0, -0); // bytes: 80 0 0 0 0 0 0 0
dv2.setFloat64(0, dv1.getFloat64(0)); // bytes: 80 0 0 0 0 0 0 0We actually ran into this a few years back (see nodejs/node-v0.x-archive#4648) where clang32 was forcing sNaN and causing tests to fail (see https://llvm.org/bugs/show_bug.cgi?id=15054) But since you're not checking the exact bit-wise pattern none of the above matters. |
|
Ah, cool – didn’t know that. And yep, this gives just even more justification for not checking the bit pattern. |
|
@addaleax hey, CI is green - I was going to land it but seeing you're up for addition as collaborator I figured I'd give you a chance to touch up your commit message yourself. Currently, it's missing the To All the lines should be under 70 characters but that is already the case in this PR. Please let me know when you've amended the commit message or alternatively if you don't feel like it I don't mind landing this and doing it for you as we usually do for non-collaborators. |
Do not convert typed arrays to `Buffer` for deepEqual since their values may not be accurately represented by 8-bit ints. Instead perform binary comparison of underlying `ArrayBuffer`s, but only when the array types match. Never apply any kind of optimization for floating-point typed arrays since bit pattern equality is not the right kind of check for them. PR-URL: nodejs#5910 Reviewed-By: Benjamin Gruenbaum <[email protected]> Fixes: nodejs#5907
addaleax
force-pushed
the
assert-typed-array-types
branch
from
e91e6b7
to
b4baf19
Compare
|
@benjamingr Thanks! I think I got this right. I rebased against master; if that’s something you don’t like around here after having run the CI, I can undo that, but I don’t think that would make a lot of sense? |
|
@benjamingr whoever lands the commit generally adds the metadata like PR-URL and Reviewed-By (or I've always thought so :]). |
|
@evanlucas yes, I wondered if addaleax would like the practice :) I don't offer/ask this normally. |
|
@benjamingr ah apologies. I should have kept up with the conversation better :] |
Do not convert typed arrays to `Buffer` for deepEqual since their values may not be accurately represented by 8-bit ints. Instead perform binary comparison of underlying `ArrayBuffer`s, but only when the array types match. Never apply any kind of optimization for floating-point typed arrays since bit pattern equality is not the right kind of check for them. PR-URL: #5910 Reviewed-By: Benjamin Gruenbaum <[email protected]> Fixes: #5907
|
Landed in cf94929 - thanks for the surgical fix :) |
|
If I understand correctly, this should probably be marked lts-watch-v4.x since the original PR which introduced this bug (#4330) was labelled the same way? |
Do not convert typed arrays to `Buffer` for deepEqual since their values may not be accurately represented by 8-bit ints. Instead perform binary comparison of underlying `ArrayBuffer`s, but only when the array types match. Never apply any kind of optimization for floating-point typed arrays since bit pattern equality is not the right kind of check for them. PR-URL: #5910 Reviewed-By: Benjamin Gruenbaum <[email protected]> Fixes: #5907
|
@addaleax this is not landing cleanly as it looks like there have been some semver major changes to assert. Would you be able to manually back port this to |
Do not convert typed arrays to `Buffer` for deepEqual since their values may not be accurately represented by 8-bit ints. Instead perform binary comparison of underlying `ArrayBuffer`s, but only when the array types match. Never apply any kind of optimization for floating-point typed arrays since bit pattern equality is not the right kind of check for them. PR-URL: nodejs#5910 Reviewed-By: Benjamin Gruenbaum <[email protected]> Fixes: nodejs#5907
|
@thealphanerd Yup, here it is: #6147 :) |
Do not convert typed arrays to `Buffer` for deepEqual since their values may not be accurately represented by 8-bit ints. Instead perform binary comparison of underlying `ArrayBuffer`s, but only when the array types match. Never apply any kind of optimization for floating-point typed arrays since bit pattern equality is not the right kind of check for them. PR-URL: #5910 Reviewed-By: Benjamin Gruenbaum <[email protected]> Fixes: #5907
Pull Request check-list
make -j8 test(UNIX) orvcbuild test nosign(Windows) pass withthis change (including linting)?
test (or a benchmark) included?
Affected core subsystem(s)
assert
Description of change
Do not convert typed arrays to
Bufferfor deepEqual since their values may not be accurately represented by 8-bit ints. Instead perform binary comparison of underlyingArrayBuffers, but only when the array types match.Never apply any kind of optimization for floating-point typed arrays since bit pattern equality is not the right kind of check for them.
Fixes: #5907 (introduced in #4330)