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_graphic
and 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 23 2024 at 12:05 UTC