-
Notifications
You must be signed in to change notification settings - Fork 68
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
Introduce a PointerBuffer class for wrapping pointers #64
base: latest
Are you sure you want to change the base?
Conversation
@nshmyrev - If you have a moment, would you be able to take a look at the fix for the build failure I made in the last commit? I'm not very strong with C++ (although I know C well), so I don't think my fix is right. Perhaps the real fix might be just a compiler argument that's missing? So that you don't have to go digging, the build error was:
The failure looks like it's caused by this line in
However, I couldn't get the failure to happen locally on my mac - so there's something about the CI build that's different. The documented API for Since the private method it was complaining about just calls |
An aside / question about node 10 for @addaleax - while trying to figure out what was going on with the build, I bumped the version of The node 10 tests still appear to pass - but since node 10 is EOL (and this PR is a major version bump anyway), do you want to drop node 10 support here too? If you don't want to do that, I can back out the version bump - it wasn't part of the fix. Either way, I added node 16 to the appveyor build. |
Is there anything more I can do to help get this moving? It would be very useful for us (and others, I'm sure), |
Yeah, it probably makes sense to do this here 👍
Yeah, I’m sorry that I don’t have much spare time for review, but it’s at the top of my list :) And I am really grateful for you putting in the work here! 💙 One thing that I would really like to try/do is to use |
@@ -14,7 +14,6 @@ class Instance { | |||
public: | |||
virtual napi_value WrapPointer(char* ptr, size_t length) = 0; | |||
virtual char* GetBufferData(napi_value val) = 0; | |||
virtual void RegisterArrayBuffer(napi_value val) = 0; | |||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can get rid of this file entirely, right?
Napi::Number value = info[0].As<Napi::Number>(); | ||
ptr_ = reinterpret_cast<char *>(value.Int64Value()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The JS number type can’t accurately represent 64-bit values, so this will not work as-is, I am afraid :/
if (encoding == "utf-8") { | ||
return String::New(info.Env(), ptr_, length_); | ||
} else if (encoding == "ucs2") { | ||
return String::New(info.Env(), reinterpret_cast<char16_t*>(ptr_), length_ / 2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d probably just provide a way to read a slice of N bytes starting this pointer as a Buffer (but as a copy, not backed by this address), and then use .toString()
on that, so that we keep being compatible with existing code
throw TypeError::New(env, "readInt64: Cannot read from nullptr pointer"); | ||
} | ||
|
||
int32_t val = *reinterpret_cast<int32_t*>(ptr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will need to be a memcpy();
, otherwise it could be an unaligned read
throw TypeError::New(env, "writeInt32: value out of range"); | ||
} | ||
|
||
*reinterpret_cast<int32_t*>(ptr) = (int32_t)val; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto here – but I would also really maybe reconsider implementing this in C++, it would be nice to have all the string parsing etc. done in JS and then just write 4 bytes into a temporary Buffer
here + provide a method to write a Buffer into a PointerBuffer
at a given offset
Thanks for the excellent review! I don't think I have the context for the parts that require changes - @nshmyrev, are you able to take a look? |
any news here? |
I think we're at a bit of an impasse. Tim and (moreso) I don't have the context to make the necessary adjustments (I don't know C++ at all and the pointers from @addaleax might as well be speaking martian to me!) and the maintainers don't seem to have the capacity. |
Hello @addaleax & @TooTallNate , First off, incredible work! We are using this over in https://github.com/pact-foundation/pact-js for contract testing, and love open source! I am happy to help try and pick up this branch, but I am pretty new to C++ Would you have any spare capacity to help review any further changes, or potentially do a bit of pairing to get this across the line. Thanks in advance |
Thanks Yousaf. Just an update that we have shifted gears in Pact and are now doing a direct C++ integration layer with node gyp (which seems to be working nicely). So this is no longer urgent as far as our cause is concerned, but I'm sure future generations of users would appreciate the contribution. Thanks again for your support to date, whilst we're not likely to use this anymore it got us onto a path of native integration we may never have attempted otherwise. |
@addaleax How much remaining effort is required to get this PR over the finish line? This seems to break users in Node 13-16, and given that Node 17 + 18 are not currently LTS releases, some users can't depend on upgrading to newer versions of Node yet. I don't have the expertise required to contribute here, but it would be great to know if there is any path forward for this PR. |
This is the code that @nshmyrev mentioned on #54. It's entirely their code - my only contributions are to merge in the latest upstream changes, confirm the tests pass, and then create this PR.
Note that it introduces a version bump to the next major version. I'm unclear on what the breaking changes are, so I haven't contributed release notes. If needing the release notes will block the merge, then I am happy to read the code and find out.
Once this is merged, I will make a PR for the parent repository, using the fork @nshmyrev mentioned in this comment - #54 (comment)
Please let me know if there is any work that needs to be done before this can be merged.