tls_wrap: clear errors on return

[indutny]

Adopt ClearErrorOnReturn from node_crypto.cc, and use it to clear
errors after SSL_read/SSL_write/SSL_shutdown functions.

See: #4485

[indutny]

I'm not sure how the test case should look like, but this PR fixes #4485 on v0.12 branch.

[bnoordhuis]

I think you can drop this line now. IIRC, that was a workaround for a false positive in gcc 4.2 or 4.4.

[bnoordhuis]

LGTM with a suggestion. Maybe it's better to use MarkPopErrorOnReturn instead though?

[indutny]

Thank you, force pushed. CI: https://ci.nodejs.org/job/node-test-pull-request/1141/

[indutny]

Failures seems to be unrelated, but just in case: https://ci.nodejs.org/job/node-test-pull-request/1142/

[bnoordhuis]

LGTM

[indutny]

Landed in 4f87574, thank you!

[MylesBorins]

@indutny it appears this change is relying on changes to crypto that haven't landed on v4.x yet.

I think it might be related to #4127 but I have not fully dug in. I will revisit this when we do our next release

[indutny]

@thealphanerd Argh, is it because of the set_mark thing? What exactly happens?

[MylesBorins]

++<<<<<<< 2192fc8e890be53ee2213740c3cba2656affefb3
 +// Forcibly clear OpenSSL's error stack on return. This stops stale errors
 +// from popping up later in the lifecycle of crypto operations where they
 +// would cause spurious failures. It's a rather blunt method, though.
 +// ERR_clear_error() isn't necessarily cheap either.
 +struct ClearErrorOnReturn {
 +  ~ClearErrorOnReturn() { ERR_clear_error(); }
 +};
 +
++=======
++>>>>>>> tls_wrap: clear errors on return

I didn't dig in too deep, but usually those kind of conflicts are due to missing patch's.

[indutny]

@thealphanerd this patch should do it: https://gist.github.com/indutny/41e1992a45b1cb0b062e

[MylesBorins]

making sure we are on the same is the above patch a replacement for this commit or something to put in first? If you don't mind would you be willing to wrap that all up in a single PR and submit against v4.x-staging?

[indutny]

@thealphanerd it is just a resolved conflicts. See #4687