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.
lpereira requested pchickey for a review on PR #8716.
lpereira requested wasmtime-core-reviewers for a review on PR #8716.
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?
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.)
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_graphicand call it a day. @alexcrichton, what do you think?
lpereira commented on PR #8716:
Looking at the docs: yeah, that seems like a good idea.
lpereira updated PR #8716.
Last updated: Dec 13 2025 at 19:03 UTC