Skip to content
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

n-api: add napi_get_node_version #14696

Closed
wants to merge 1 commit into from

Conversation

addaleax
Copy link
Member

@addaleax addaleax commented Aug 8, 2017

Add napi_get_node_version, to help with feature-detecting Node.js as an environment.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

N-API

/cc @nodejs/n-api

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Aug 8, 2017
@addaleax addaleax added node-api Issues and PRs related to the Node-API. semver-minor PRs that contain new features and should be released in the next minor version. and removed lib / src Issues and PRs related to general changes in the lib or src directory. labels Aug 8, 2017
doc/api/n-api.md Outdated

- `[in] env`: The environment that the API is invoked under.
- `[out] versions`: A pointer to an array of length 3.
- `[out] release`: Optional A string identical to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Period after Optional and after process.release.name.

src/node_api.cc Outdated
versions[0] = NODE_MAJOR_VERSION;
versions[1] = NODE_MINOR_VERSION;
versions[2] = NODE_PATCH_VERSION;
if (release != nullptr) *release = NODE_RELEASE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a test where release is null.

src/node_api.cc Outdated
@@ -3088,6 +3088,18 @@ napi_status napi_get_version(napi_env env, uint32_t* result) {
return napi_clear_last_error(env);
}

napi_status napi_get_node_version(napi_env env,
uint32_t* versions,
const char** release) {
Copy link
Contributor

@kfarnung kfarnung Aug 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

src/node_api.cc Outdated
@@ -3088,6 +3088,18 @@ napi_status napi_get_version(napi_env env, uint32_t* result) {
return napi_clear_last_error(env);
}

napi_status napi_get_node_version(napi_env env,
uint32_t* versions,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to use a struct here? I see two benefits:

  • No need for the developer to study the documentation to determine the size of the array required
  • Easier to access the parts of the version by member name

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, that makes sense. I’ll push again in a couple minutes.

@addaleax
Copy link
Member Author

addaleax commented Aug 8, 2017

@kfarnung I’ve updated this anyway with the struct approach and clarified that the returned buffer is statically allocated, please take a look :)

NODE_PATCH_VERSION,
NODE_RELEASE
};
*result = &version;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@kfarnung kfarnung Aug 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on the current approach.

Copy link
Contributor

@kfarnung kfarnung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bnoordhuis
Copy link
Member

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?

@jasongin
Copy link
Member

jasongin commented Aug 8, 2017

the env argument isn't (meaningfully) used. Maybe remove it?

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:

  1. Consistency
  2. N-API implementation on other VMs may require a context even if it isn't needed for V8.
  3. If/when node supports multiple environments/isolates in a process we will be able to update the implementation without having breaking changes.

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.

@addaleax
Copy link
Member Author

CI: https://ci.nodejs.org/job/node-test-commit/11696/

This should be ready.

uint32_t minor;
uint32_t patch;
const char* release;
} napi_node_version;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense for this struct to also include the dependency version details equivalent to process.versions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. :)

@addaleax
Copy link
Member Author

addaleax commented Aug 12, 2017

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>
@addaleax
Copy link
Member Author

Landed in 835c383

@addaleax addaleax closed this Aug 12, 2017
@addaleax addaleax deleted the napi-node-version branch August 12, 2017 19:29
addaleax added a commit that referenced this pull request Aug 12, 2017
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>
addaleax added a commit that referenced this pull request Aug 12, 2017
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>
@addaleax addaleax mentioned this pull request Aug 13, 2017
gabrielschulhof pushed a commit to gabrielschulhof/node that referenced this pull request Apr 10, 2018
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>
MylesBorins pushed a commit that referenced this pull request Apr 16, 2018
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>
@MylesBorins MylesBorins mentioned this pull request Apr 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. node-api Issues and PRs related to the Node-API. semver-minor PRs that contain new features and should be released in the next minor version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants