Compile and Run C in JavaScript
1–10 of 31 posts
Re: Compile and Run C in JavaScript
#2To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen and include paths. Also added support for parsing the deprecated attribute used in lots of Darwin headers. C parsers seem a lot simpler than JavaScript which is nice
Re: Compile and Run C in JavaScript
#3Re: Compile and Run C in JavaScript
#4This was an unplanned feature I worked on mostly a month ago on a Saturday for fun. Happy to answer any questions To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen and include paths. Also added support for parsing the deprecated attribute used in lots of Darwin headers. C parsers seem a lot simpler than JavaScript which is nice
From my (admittedly limited) knowledge on this space, it seems like this is a straight upgrade over WASM, with the only limiting factor being that your stack is limited to Bun + C. Are there any downsides of this feature when compared with the alternatives mentioned at the start of the article? There are some tradeoffs listed at the bottom but I'm not sure how napi/WASM perform in those aspects either.
Re: Compile and Run C in JavaScript
#5This was an unplanned feature I worked on mostly a month ago on a Saturday for fun. Happy to answer any questions To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen and include paths. Also added support for parsing the deprecated attribute used in lots of Darwin headers. C parsers seem a lot simpler than JavaScript which is nice
Re: Compile and Run C in JavaScript
#6Re: Compile and Run C in JavaScript
#7Re: Compile and Run C in JavaScript
#8Bun: 6.7410ms Bun FFI w/ C: 6.0413ms Node: 5.1307ms C only: 4.3ms (+- 1ms)
I'm generally very bullish on Bun and was very happy with the DX for this C api. Great work to Jarred and the team!!!
benchmark code: https://github.com/tscircuit/bun-ffi-benchmarking
Re: Compile and Run C in JavaScript
#9I wonder about the security of this. Are programs executed in some kind of jail? Is there a limit to certain features, e.g., opening a socket to somewhere?
> However, for system libraries, WebAssembly's isolated memory model comes with serious tradeoffs.
> Isolation means no system calls WebAssembly can only access functions the runtime exposes to it. Usually, that's JavaScript.
Without digging into the code I'm going to assume (guess) that this feature did not take the main value-prop of the WASM model.
Afaik, this is explicitly against the isolation that WASM imposes [1]
> Modules must declare all accessible functions and their associated types at load time, even when dynamic linking is used. This allows implicit enforcement of control-flow integrity (CFI) through structured control-flow.
I seem to remember a WASI developer talk that discussed syscalls here, but I can't remember the specifics. The gist was basically along the lines of, "syscalls are a level of privilege that should not be cart-blanche accessible to all programs at all times"
Re: Compile and Run C in JavaScript
#10This was an unplanned feature I worked on mostly a month ago on a Saturday for fun. Happy to answer any questions To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen and include paths. Also added support for parsing the deprecated attribute used in lots of Darwin headers. C parsers seem a lot simpler than JavaScript which is nice