First step on N-API porting #196
Conversation
|
@bnoordhuis are you going to have a chance to take a look at this updated version? |
| rc->Set(0, Nan::New<Integer>(static_cast<uint32_t>(input_consumed))); | ||
| rc->Set(1, Nan::New<Integer>(static_cast<uint32_t>(output_consumed))); | ||
| info.GetReturnValue().Set(errorno); | ||
| rc.Set(static_cast<uint32_t>(0), Napi::Number::New(env, static_cast<uint32_t>(input_consumed))); |
There was a problem hiding this comment.
For my edification, this static_cast<uint32_t>(0) is necessary because rc.Set(0, ...) is ambiguous w.r.t. to the overload that takes a char pointer?
There was a problem hiding this comment.
It's necessary because you can only pass this types to Set method:
napi_valueNapi::Valueconst char*const std::string&uint32_t
in alternative it could be possible do the same thing like reported below:
rc.Set(Napi::Number::New(env, 0), Napi::Number::New(env, static_cast<uint32_t>(input_consumed)));
rc.Set(Napi::Number::New(env, 1), Napi::Number::New(env, static_cast<uint32_t>(output_consumed)));What do you prefer?
|
@bnoordhuis any chance you can review again after @NickNaso rebases. |
|
@NickNaso Sorry for the delay. Can you make sure you rebase against rather than merge in master? Your PR currently has some changes intermixed that already exist in master. I tried to rebase it myself but there are conflicts in src/binding.cc. |
|
@bnoordhuis Sorry for delay on working on this. Could you take a look and send your feedback? |
Hi everyone,
I'm opening a new PR about the N-API porting because I want work on this work and I don't have write access to the previous PR (#189) - I tried to contact the developer that started the the porting work but I never received any answer.
If possible please review this PR to move forward on ending this porting.