Uh oh!
There was an error while loading. Please reload this page.
[v8.x backport] crypto: do not reach into OpenSSL internals for ThrowCryptoError - #18327
[v8.x backport] crypto: do not reach into OpenSSL internals for ThrowCryptoError#18327yhwang wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Since algorithm header is added above and cmath is included in algorithm, the standard isnan and isinf macros are undefined and new functions are introduced under std namespace. Therefore, need to use std namespace for these 2 functions.
You can see more detailed information in cmath header.
gibfahn
commented
Jan 23, 2018
@bnoordhuis could you confirm that this makes sense? |
CI: https://ci.nodejs.org/job/node-test-commit/15625/ EDIT: Wrong job, trying again: https://ci.nodejs.org/job/node-test-commit/15632/ |
68a631f to
aff27a1Comparead97c44 to
357ea02Compareyhwang
commented
Jan 24, 2018
rebased my branch to upstream/v8.x-staging. and 2 test cases failed in windows: I saw another v8.x backport PR also has the same failures. |
gibfahn
commented
Jan 24, 2018
yhwang
commented
Jan 24, 2018
The results are the same as the first one. These 2 test cases still failed in Windows: |
bnoordhuis
commented
Jan 25, 2018
@yhwang Can you rebase? The test failures are known flakes. |
357ea02 to
08bad94Compareyhwang
commented
Jan 25, 2018
@bnoordhuis I just rebased. Please kick off another CI to verify it. Thanks. |
gibfahn
commented
Jan 26, 2018
bnoordhuis
commented
Feb 2, 2018
@yhwang I'm afraid this needs another rebase. |
08bad94 to
de47005Compare@bnoordhuis sure thing and it's done. [Edit] Please kick off a CI to verify it it |
de47005 to
d13ac52Compareyhwang
commented
Feb 7, 2018
Rebase again because of the conflict and please kick off a CI. Thanks. |
mhdawson
commented
Feb 9, 2018
yhwang
commented
Feb 12, 2018
failed on windows-test. it complains about |
gibfahn
commented
Feb 18, 2018
Sorry @yhwang , looks like this needs (yet another) rebase after the V8 update. |
rebase failed and need to solve lots of conflict in v8. Let me use a new branch which is from the latest v8.x-staging. that's will be easier. |
There is a perfectly serviceable ERR_get_error function which avoids having to sniff through the OpenSSL ring buffer like that. It does return the errors in the opposite order, but that's easily fixed with std::reverse. Note this behavior is slightly different in that an ERR_get_error loop will ultimately clear the error queue, but this is desirable. Leaving the error queue uncleared means errors in subsequent operations may get mixed up and cause issues. PR-URL: nodejs#16701 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
d13ac52 to
c96e3c9Compareyhwang
commented
Feb 19, 2018
gibfahn
commented
Feb 20, 2018
Yeah I frequently just do |
gibfahn
commented
Feb 20, 2018
@bnoordhuis would you mind taking a quick look? |
There is a perfectly serviceable ERR_get_error function which avoids having to sniff through the OpenSSL ring buffer like that. It does return the errors in the opposite order, but that's easily fixed with std::reverse. Note this behavior is slightly different in that an ERR_get_error loop will ultimately clear the error queue, but this is desirable. Leaving the error queue uncleared means errors in subsequent operations may get mixed up and cause issues. PR-URL: #16701 Backport-PR-URL: #18327 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
gibfahn
commented
Feb 20, 2018
Landed in 8cc0ea7 |
There is a perfectly serviceable ERR_get_error function which avoids
having to sniff through the OpenSSL ring buffer like that. It does
return the errors in the opposite order, but that's easily fixed with
std::reverse.
Note this behavior is slightly different in that an ERR_get_error loop
will ultimately clear the error queue, but this is desirable. Leaving
the error queue uncleared means errors in subsequent operations may get
mixed up and cause issues.
Original PR-URL: #16701
Reviewed-By: Ben Noordhuis info@bnoordhuis.nl