-
Notifications
You must be signed in to change notification settings - Fork 714
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
Strange symbols don't roundtrip through wasm2wat and wat2wasm #685
Comments
Ah, I see! Yeah, this seems to be a limitation of the text format, since any utf-8 sequence is allowed for a name in the binary format. For now, I guess I wasn't able to repro the segfault though, here's what I tried:
|
We should add a way to express all names that are valid in the binary format in the text format. Until then, it's better to be able to produce a valid `wat` file. See issue #685.
We should add a way to express all names that are valid in the binary format in the text format. Until then, it's better to be able to produce a valid `wat` file. See issue #685.
We should add a way to express all names that are valid in the binary format in the text format. Until then, it's better to be able to produce a valid `wat` file. See issue #685.
Closing as this no longer segfaults or produces an error, although the question of roundtrippability, and the issue to be fixed by #1661, still seem outstanding. |
Over in alexcrichton/wasm-gc#8 I'm experimenting with demangling rust symbols in wasm output. This results in symbol names such as
<alloc::vec::Vec<T>>::extend_from_slice
and<&'a T as core::fmt::Debug>::fmt
.While
wasm2wat
produces very nice looking output, I get a segmentation fault when feeding this output back intowat2wasm
. I'm guessing that the space characters are causing issues when parsing the.wat
file but other characters could be causing problems as well.example.wasm.gz
The text was updated successfully, but these errors were encountered: