SyntaxError when exporting name containing period

[rdb]

When exporting a name containing a full stop character, emscripten generates a JavaScript file containing invalid syntax.

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.2 (7591f1c5ea0adf6f4293cfba2995ee9700aa0d93)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 9534d27e3321a3b9e6e79fe6328445575bf26b7b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/rdb/local/src/emsdk/upstream/bin

Failing command line in full:

emcc -o test.js -x c - << EOF
__attribute__((export_name("my.func")))
void myfunc() {
}
EOF
node test.js

Output:

/tmp/test.js:955
var _my.func = Module['_my.func'] = createExportWrapper('my.func', 0);
       ^

SyntaxError: Unexpected token '.'
    at wrapSafe (node:internal/modules/cjs/loader:1378:20)
    at Module._compile (node:internal/modules/cjs/loader:1428:41)
    at Module._extensions..js (node:internal/modules/cjs/loader:1548:10)
    at Module.load (node:internal/modules/cjs/loader:1288:32)
    at Module._load (node:internal/modules/cjs/loader:1104:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:173:12)
    at node:internal/main/run_main_module:28:49

Node.js v20.18.1

Full link command and output with -v appended:

 /home/rdb/local/src/emsdk/upstream/bin/clang -target wasm32-unknown-emscripten -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --sysroot=/home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot -DEMSCRIPTEN -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -v -xc -c - -o /tmp/emscripten_temp_8m5w0anc/-_0.o
clang version 21.0.0git (https:/github.com/llvm/llvm-project 9534d27e3321a3b9e6e79fe6328445575bf26b7b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/rdb/local/src/emsdk/upstream/bin
 (in-process)
 "/home/rdb/local/src/emsdk/upstream/bin/clang-21" -cc1 -triple wasm32-unknown-emscripten -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic -fvisibility=hidden -debugger-tuning=gdb -fdebug-compilation-dir=/tmp -v -fcoverage-compilation-dir=/tmp -resource-dir /home/rdb/local/src/emsdk/upstream/lib/clang/21 -D EMSCRIPTEN -isysroot /home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot -internal-isystem /home/rdb/local/src/emsdk/upstream/lib/clang/21/include -internal-isystem /home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten -internal-isystem /home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/include -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fignore-exceptions -iwithsysroot/include/fakesdl -iwithsysroot/include/compat -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o /tmp/emscripten_temp_8m5w0anc/-_0.o -x c -
clang -cc1 version 21.0.0git based upon LLVM 21.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten"
#include "..." search starts here:
#include <...> search starts here:
 /home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/include/fakesdl
 /home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/include/compat
 /home/rdb/local/src/emsdk/upstream/lib/clang/21/include
 /home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/include
End of search list.
 /home/rdb/local/src/emsdk/upstream/bin/clang --version
 /home/rdb/local/src/emsdk/upstream/bin/wasm-ld -o test.wasm -L/home/rdb/local/src/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -L/home/rdb/local/src/emsdk/upstream/emscripten/src/lib /tmp/emscripten_temp_8m5w0anc/-_0.o -lGL-getprocaddr -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc-debug -lcompiler_rt -lc++-noexcept -lc++abi-debug-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /tmp/tmpm796_y4ylibemscripten_js_symbols.so --strip-debug --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_get_current --export=emscripten_stack_init --export=_emscripten_stack_alloc --export=__wasm_call_ctors --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=fflush --export-table -z stack-size=65536 --no-growable-memory --initial-heap=16777216 --no-entry --stack-first --table-base=1
 /home/rdb/local/src/emsdk/upstream/bin/llvm-objcopy test.wasm test.wasm --remove-section=.debug* --remove-section=producers --remove-section=name
 /home/rdb/local/src/emsdk/node/20.18.0_64bit/bin/node /home/rdb/local/src/emsdk/upstream/emscripten/src/compiler.mjs /tmp/tmp_lvkwr0b.json

[sbc100]

Its expected that all exported symbols are valid C/LLVM symbols. Allowing otherwise would likely be a fair amount of work. Do you have a strong use cases for needing such symbols? I'm tempted to add a check earilier on so at least you get a nice error message.

[rdb]

It was just unexpected to hit this, given that in wasm this is valid and not uncommon. My use case was running the wasm through wizer, which requires a wizer.initialize export, though it's possible to work around this by telling wizer to use a different name.

If it is not going to be supported then an earlier error message would be appropriate, rather than generating invalid JS code.

[sbc100]

For now I think the quick fix is to make this rule explicit: #23563.

We could looks into relaxing this in the future if there is enough demand.

[dschuff]

#23563 seems fine as it documents an existing limitation, but in principle I don't think export names should be limited to valid C identifiers, even when used in C as in this case. The set of allowed identifiers in e.g. assembly is bigger than C, and this is very useful for compilers (i.e. they generate lots of identifiers beginning with . and can avoid collisions).
It is a bit unfortunate that we have this limitation - and of course the actual limitation is a bit more subtle, because it's actually valid JS identifiers that are required, not C (I'm not sure if there's a difference).

Having said all that, @sbc100 is right that there would probably need to be mangling or similar in a bunch of places in emscripten, with a nontrivial chance of breaking users who accidentally depend on it (or intentionally? Is "just use a JS var of the same name as your export" a recommended way to get exports in any context? e.g. in post-JS or EM_ASM?). So it's not clear whether we should actually fix this.

[sbc100]

(i.e. they generate lots of identifiers beginning with . and can avoid collisions

I'm not sure about that. I don't think symbols that begin with . can be generated by the assembler, at least not public symbols that end up in the linker symbol table. Maybe they can be used for internal/local symbols.

[sbc100]

(i.e. they generate lots of identifiers beginning with . and can avoid collisions

I'm not sure about that. I don't think symbols that begin with . can be generated by the assembler, at least not public symbols that end up in the linker symbol table. Maybe they can be used for internal/local symbols.

Actually it looks like you are correct, I can use the assembler to generate symbols that start with .!

[rdb]

Do we actually need the names to be valid JS identifiers for this to be allowed? We can already refer to them as Module['my.func'] and I would personally not mind if no global alias were created for one that is not a valid identifier.

It seems like a fix that is just as easy to make and less restrictive than the proposed error message.

[sbc100]

I think its a reasonable feature request, but like all emscripten features it would come at a cost. For example, it will make these symbols different to all other exported symbols, which could cause confusion. Simply banning these symbols seems like the conservative thing to do until we have a good idea about the use cases and impact.

For example, do you actually want to be able to call Module['wizer.initialize'] form the outsize? What is the purpose of thise symbol and when does it want to be called? What if some other user want to export these symbol but not export them onto the public Module object (i.e. as internal-only JS symbols)?

[rdb]

It's not something I actually want to call from the environment that the js is generated for, no. It's used by a tool that runs directly on the wasm (using wasmtime). If emscripten has a mechanism to exclude exports from the generated .js but not from the .wasm, I would be very happy to hear about it.

[sbc100]

As of today, emscripten treats all "unexpected" exports as user-requested exports. i.e. exports that the user wants available on the public Module object.

This is how the EMSCRIPTEN_KEEPALIVE source annotation functions.

Ideally we could tease apart the list of keep alive symbols and ignore other unexpected exports but that is not possible today.

BTW, in your case is the wasm file not generated by emscripten / wasm-ld? Are you using the --post-link flag maybe? Otherwise I don't see how this symbol could be in the wasm in the first place.

[rdb]

It is generated by emcc without special flags. I'm using both EMSCRIPTEN_KEEPALIVE and export_name in order to get this symbol in the wasm export table (not sure I've checked whether the former is necessary, but I infer that it is from what you're saying).