feat(c-api) Add the WASMER_VERSION* constants, and the wasmer_version* functions

[Hywan]

Fix #1534.

Description

This PR adds the wasmer_version. It compute a string based on the CARGO_PKG_VERSION environment variable value at compile-time. I know an enum could be better, but it's a start.

This PR adds 4 C constants:

#define WASMER_VERSION "1.0.0-beta1"
#define WASMER_VERSION_MAJOR 1
#define WASMER_VERSION_MINOR 0
#define WASMER_VERSION_PATCH 0
#define WASMER_VERSION_PRE "beta1"

Thay way, the user can query the version of Wasmer more easily.

In addition, it adds 4 functions (when the header files aren't accessible):

const char* wasmer_version(void);
uint8_t wasmer_version_major(void);
uint8_t wasmer_version_minor(void);
uint8_t wasmer_version_patch(void);
const char* wasmer_version_pre(void);

Review

• Add a short description of the the change to the CHANGELOG.md file

[Hywan]

bors try

[bors]

try

Build succeeded:

• Test on macos-x64
• Audit
• Code lint
• Test on linux-x64
• Test on windows-x64
• Test on linux-aarch64
• Test cross-compile on linux
• Test cross-compile on macos

[syrusakbary]

Should it be *const c_char ?

[jubianchi]

same as @syrusakbary, why a *mut?

[Hywan]

So that the user doesn't need to cast it when freeing it. That's stupid, but I think it's a better ergonomic.

tl;dr: It avoids writing this:

const char* version = wasmer_version();
free((char*) version); // this cast

[MarkMcCaskey]

We'll need to fix the free bug before we can ship this but otherwise looks good

[MarkMcCaskey]

From the docs:

The pointer which this function returns must be returned to Rust and reconstituted using CString::from_raw to be properly deallocated. Specifically, one should not use the standard C free() function to deallocate this string.

I don't think we can ever mix C and Rust ownership: CString is an owned type on the Rust side, we can't pass it back to C without providing our own destructor. Probably simpler to have the user pass us a buffer or to return a pointer to a static string which does not need to be freed

[syrusakbary]

Note: I did the comments as an approval by mistake.

Actually, I think there might be a better solution than a function that returns a string.

Since we are generating the headers at build time, we can check what the version is for the crate, and add that as a constant string variable in the generated header file.

Thoughts @Hywan @MarkMcCaskey @jubianchi ?

[syrusakbary]

Let's use:

static const char * WASMER_VERSION = "1.0.0";

[MarkMcCaskey]

Note: I did the comments as an approval by mistake.

Actually, I think there might be a better solution than a function that returns a string.

Since we are generating the headers at build time, we can check what the version is for the crate, and add that as a constant string variable in the generated header file.

Thoughts @Hywan @MarkMcCaskey @jubianchi ?

Yeah, that makes sense, though we should probably use a C macro:

#define WASMER_VERSION "version-number"

because static variables take up space and can collide with each other when linking and stuff

[MarkMcCaskey]

Actually, this has one major draw back... perhaps we want to do both, but it's nice to have a standard API for querying which version of Wasmer you're running against. This will be important with 1.0.0 when we have more claims to stability and users may ship code that dynamically links against the Wasmer C API and may want to query what version it's running against

[syrusakbary]

Actually, this has one major draw back... perhaps we want to do both, but it's nice to have a standard API for querying which version of Wasmer you're running against. This will be important with 1.0.0 when we have more claims to stability and users may ship code that dynamically links against the Wasmer C API and may want to query what version it's running against

Yup, that's the same I was thinking. Let's do it via macro and static string then?

[MarkMcCaskey]

Actually, this has one major draw back... perhaps we want to do both, but it's nice to have a standard API for querying which version of Wasmer you're running against. This will be important with 1.0.0 when we have more claims to stability and users may ship code that dynamically links against the Wasmer C API and may want to query what version it's running against

Yup, that's the same I was thinking. Let's do it via macro and static string then?

Yeah, a static string works but the static has to be defined on the Rust side, not the C side, or it has the same problem as the macro

[Hywan]

Actually, I think there might be a better solution than a function that returns a string.

Of course there is! This PR was a kickstart for the discussion :-).

[Hywan]

I wonder whether it's required to add a C function for that. I've added the following C constants, and I believe the user can query everything that is common with those:

#define WASMER_VERSION "1.0.0-beta1"
#define WASMER_VERSION_MAJOR 1
#define WASMER_VERSION_MINOR 0
#define WASMER_VERSION_PATCH 0
#define WASMER_VERSION_PRE "beta1"

Note that _MAJOR, _MINOR and _PATCH are integers, not strings.

Thoughts?

[Hywan]

bors try

[bors]

try

Build succeeded:

• Audit
• Code lint
• Test on linux-x64
• Test on macos-x64
• Test on windows-x64
• Test cross-compile on macos
• Test on linux-aarch64
• Test cross-compile on linux

[syrusakbary]

Yeah, a static string works but the static has to be defined on the Rust side, not the C side, or it has the same problem as the macro

This was not addressed @Hywan

[jubianchi]

Seems good but:

• What about having wasmer_version_major(), wasmer_version_minor(), wasmer_version_patch()?
• We also have to expose the pre-release part if we want a "full" API;

[Hywan]

bors r+

[bors]

Build succeeded:

• Audit
• Code lint
• Test on windows-x64
• Test on linux-x64
• Test on linux-aarch64
• Test cross-compile on macos
• Test on macos-x64
• Test cross-compile on linux