Progress on
https://github.com/kripken/emscripten/issues/2596
has landed on incoming, specifically we now emit EM_ASM contents as normal
JS functions inside the .js file that emscripten emits. They are outside of
the asm.js module, but they are JS code now, compared to before when they
were read as strings from the C heap and evalled.
The benefit is that we can avoid evalling in order to use EM_ASM. (That
also means you can use the WebIDL binder without using eval, as it uses
EM_ASM.) Avoiding eval is both faster and avoids some issues with JS static
analyzers that look for eval and flag it as a security concern.
This does however change EM_ASM if you are using closure compiler. The
difference is that before, closure couldn't see the code, so
EM_ASM( do({ prop: value }) );
would be run exactly as it looks. However, now the do({ prop: value })
code is visible to closure, and it might emit
do({ a: value })
i.e. it might minify the property name. Normally this is fine and
beneficial - letting closure see everything means it can minify across the
entire program, which now includes EM_ASM blocks, but you might need to be
aware of it in some cases.
If you are not using closure compiler, you don't need to worry about this;
if you are, you are probably already familiar with this topic, this is just
a heads up that EM_ASM blocks are now relevant to it.
- Alon
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
