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

vec<T>::make_nt may not be so helpful #187

Open
jiahaog opened this issue Nov 30, 2023 · 1 comment
Open

vec<T>::make_nt may not be so helpful #187

jiahaog opened this issue Nov 30, 2023 · 1 comment

Comments

@jiahaog
Copy link

jiahaog commented Nov 30, 2023

I refer to vec<T>::make_nt:

wasm-c-api/include/wasm.hh

Lines 154 to 158 in 2ce1367

static auto make_nt(std::string s) -> vec<char> {
auto v = vec(s.length() + 1);
if (v) std::strcpy(v.get(), s.data());
return v;
}

This is implemented using std::strcpy, which stops copying when it encounters \0. It seems like more often than not, it's used to hold bytes of a Wasm binary (as a vec<byte_t>). But Wasm binaries start with \0asm, so nothing will be copied.

I'm not sure if there are other specializations where stopping at the first \0 makes sense. Considering that we already have vec::make(std::string), perhaps vec::make_nt isn't so helpful and we may want to consider removing it.

#149 is also related.

@rossberg
Copy link
Member

Hm, it would probably make more sense for this to take a const char*.

As for use case, byte vectors aren't just used for module binaries, names are the relevant case for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants