-
Notifications
You must be signed in to change notification settings - Fork 34
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
napi_call_function (and maybe others) - we assume napi_value passed in is not NULL #227
Comments
It looks like we're missing calls to both I do agree that it might make sense to allow
|
@jasongin Why? I’ve noticed that |
OK, that would be my mistake then. I didn't realize strict mode changed that behavior. (I don't normally write JavaScript code that relies on the default value of |
We left out null-checks for many of the parameters passed to our APIs. In particular, arguments of type `napi_value` were often accepted without a null-check, even though they should never be null. Additionally, many APIs simply returned `napi_ok` on success. This leaves in place an error that may have occurred in a previous N-API call. Others (those which perform `NAPI_PREAMBLE(env)` at the top) OTOH explicitly clear the last error before proceeding. With this modification all APIs explicitly clear the last error on success. Fixes nodejs#227
We left out null-checks for many of the parameters passed to our APIs. In particular, arguments of type `napi_value` were often accepted without a null-check, even though they should never be null. Additionally, many APIs simply returned `napi_ok` on success. This leaves in place an error that may have occurred in a previous N-API call. Others (those which perform `NAPI_PREAMBLE(env)` at the top) OTOH explicitly clear the last error before proceeding. With this modification all APIs explicitly clear the last error on success. Fixes nodejs#227
We left out null-checks for many of the parameters passed to our APIs. In particular, arguments of type `napi_value` were often accepted without a null-check, even though they should never be null. Additionally, many APIs simply returned `napi_ok` on success. This leaves in place an error that may have occurred in a previous N-API call. Others (those which perform `NAPI_PREAMBLE(env)` at the top) OTOH explicitly clear the last error before proceeding. With this modification all APIs explicitly clear the last error on success. Fixes nodejs/abi-stable-node#227
We left out null-checks for many of the parameters passed to our APIs. In particular, arguments of type `napi_value` were often accepted without a null-check, even though they should never be null. Additionally, many APIs simply returned `napi_ok` on success. This leaves in place an error that may have occurred in a previous N-API call. Others (those which perform `NAPI_PREAMBLE(env)` at the top) OTOH explicitly clear the last error before proceeding. With this modification all APIs explicitly clear the last error on success. Fixes: nodejs/abi-stable-node#227 PR-URL: nodejs#12539 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
We left out null-checks for many of the parameters passed to our APIs. In particular, arguments of type `napi_value` were often accepted without a null-check, even though they should never be null. Additionally, many APIs simply returned `napi_ok` on success. This leaves in place an error that may have occurred in a previous N-API call. Others (those which perform `NAPI_PREAMBLE(env)` at the top) OTOH explicitly clear the last error before proceeding. With this modification all APIs explicitly clear the last error on success. Fixes: nodejs/abi-stable-node#227 Backport-PR-URL: #19447 PR-URL: #12539 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
What if
recv
isNULL
? I am tempted to allow NULL here, because we forego an additional N-API call just to retrieve a JSundefined
as anapi_value
. Still, we should not assume that it's notNULL
.The text was updated successfully, but these errors were encountered: