Stream: git-wasmtime

Topic: wasmtime / PR #8716 Allow "." in debugging symbols


view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 21:54):

lpereira opened PR #8716 from lpereira:allow-more-characters-in-names to bytecodealliance:main:

Some programming languages, such as Go, generate symbol names with "." (e.g. git.example.com.mypackage.ExportedFunction), so allow them so they do not become question marks.

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 21:54):

lpereira requested pchickey for a review on PR #8716.

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 21:54):

lpereira requested wasmtime-core-reviewers for a review on PR #8716.

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 22:34):

jameysharp commented on PR #8716:

The golang function names I've seen have both . and / so it would be nice to allow both. On the other hand the original concern in #8627 was whether any downstream tools might mishandle these names in security-sensitive ways. Since both of these characters are significant in paths I wonder if we should worry about them?

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 22:40):

lpereira commented on PR #8716:

The golang function names I've seen have both . and / so it would be nice to allow both. On the other hand the original concern in #8627 was whether any downstream tools might mishandle these names in security-sensitive ways. Since both of these characters are significant in paths I wonder if we should worry about them?

While that's true, $ can be used for shell variable expansion, < and > for shell redirection, and @ can be used in Bash arrays. And those are already accepted.

(I wasn't sure about /, though, but I can add it too.)

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 22:49):

jameysharp commented on PR #8716:

Yeah, fair point. Maybe the main goal here is to prohibit characters outside the ASCII graphic set so nobody's dealing with nul bytes or whitespace or invalid UTF-8. If so, I'm tempted to use u8::is_ascii_graphic and call it a day. @alexcrichton, what do you think?

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 22:52):

lpereira commented on PR #8716:

Looking at the docs: yeah, that seems like a good idea.

view this post on Zulip Wasmtime GitHub notifications bot (May 30 2024 at 23:00):

lpereira updated PR #8716.


Last updated: Nov 22 2024 at 16:03 UTC