| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
Period after Optional and after process.release.name.
Sorry, something went wrong.
There was a problem hiding this comment.
Could you add a test where release is null.
Sorry, something went wrong.
There was a problem hiding this comment.
Having a string out parameter is a little bit risky since there needs to be a clear chain of ownership. In this case it will always be a constant string, but as a developer it may not be clear what the scope of the string is and whether it needs to be freed by the caller.
Sorry, something went wrong.
There was a problem hiding this comment.
but as a developer it may not be clear what the scope of the string is and whether it needs to be freed by the caller.
I can add a bit to the docs if you have a suggestion for wording, but since this refers to a const char pointer, there isn’t really any ambiguity.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks @addaleax, you're right about the const char * being a good indicator, I hadn't really considered that the object would not be a valid argument to free with the const modifier. It does seem like all usages of this function would at least yield a global string value, so I think my original concern is invalid. I'll take a look at the documentation and suggest any specific changes there.
Sorry, something went wrong.
There was a problem hiding this comment.
Would it be better to use a struct here? I see two benefits:
Sorry, something went wrong.
There was a problem hiding this comment.
Yea, that makes sense. I’ll push again in a couple minutes.
Sorry, something went wrong.
|
@kfarnung I’ve updated this anyway with the struct approach and clarified that the returned buffer is statically allocated, please take a look :) |
Sorry, something went wrong.
There was a problem hiding this comment.
Since we're returning a pointer to this static struct, should the result be a const napi_node_version** to prevent modification by the callers?
I think the other option would be to use a single indirection to a non-const napi_node_version and then just fill in the values. I'm fine either way.
Sorry, something went wrong.
There was a problem hiding this comment.
Since we're returning a pointer to this static struct, should the result be a const napi_node_version** to prevent modification by the callers?
Yes. :)
I think the other option would be to use a single indirection to a non-const napi_node_version and then just fill in the values. I'm fine either way.
I thought about that, but this approach has the advantage of being extensible on the N-API side in a backwards-compatible fashion, if we or somebody else (Node forkers?) ever need to do that.
Sorry, something went wrong.
There was a problem hiding this comment.
Agreed on the current approach.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
FWIW, libuv has two separate functions for this, one that returns a version string and one that returns major * 65536 + minor * 256 + patch. Seems simpler than having an out pointer arg. Aside: the env argument isn't (meaningfully) used. Maybe remove it? |
Sorry, something went wrong.
All the napi_* functions have a env parameter, even though a few of them don't currently use it. We do this for a few reasons:
Maybe for this particular case, items 2 and 3 will never be an issue. But still it would be strange if this API did not follow the pattern of all the others that have env as the first parameter. |
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-commit/11696/ This should be ready. |
Sorry, something went wrong.
There was a problem hiding this comment.
would it make sense for this struct to also include the dependency version details equivalent to process.versions?
Sorry, something went wrong.
There was a problem hiding this comment.
I don’t like it when N-API exposes things that are already doable by just calling into JS, using, well N-API :) This particular function might be required to check whether some of that calling-into-JS works the way you want it to.
Sorry, something went wrong.
There was a problem hiding this comment.
Well, eventually one of the goals should be for Node.js itself to use N-API internally, in which case this method would be the way to get at this information from JS :-) .. but that's down the road.
Sorry, something went wrong.
There was a problem hiding this comment.
Well, eventually one of the goals should be for Node.js itself to use N-API internally
I think N-API inherently adds too much complexity to fully replace the other APIs we use. :)
in which case this method would be the way to get at this information from JS
Adding new methods is easy, and this was implemented specifically in a way that’s easy to extend on the N-API side. :)
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-commit/11729/ |
Sorry, something went wrong.
Add `napi_get_node_version`, to help with feature-detecting Node.js as an environment. PR-URL: nodejs#14696 Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Add `napi_get_node_version`, to help with feature-detecting Node.js as an environment. PR-URL: #14696 Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Add `napi_get_node_version`, to help with feature-detecting Node.js as an environment. PR-URL: #14696 Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Add `napi_get_node_version`, to help with feature-detecting Node.js as an environment. PR-URL: nodejs#14696 Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Add `napi_get_node_version`, to help with feature-detecting Node.js as an environment. Backport-PR-URL: #19447 PR-URL: #14696 Reviewed-By: Kyle Farnung <kfarnung@microsoft.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
| Back | FazBrowse Home | New Git URL |
Add napi_get_node_version, to help with feature-detecting Node.js as an environment.
Checklist
Affected core subsystem(s)
N-API
/cc @nodejs/n-api