docs: `wasm-bindgen` supports `wasm32-unknown-emscripten`

[polarathene]

Likewise, if you're using wasm32-unknown-unknown instead of emscripten (as wasm-bindgen is only compatible with the former), you have no libc

This comment (from initial commit of the project in Nov 2020) may need to be revised as wasm-bindgen does now have support for the emscripten target (since March 2026).

I am not familiar with information conveyed here regarding emscripten + wasm-bindgen support for printf-compat, but assume that you'd be providing a printf symbol from a rust method backed by printf-compat for C/C++ to have access to at link time, and thus wasm-bindgen would be providing that for the emscripten target? 🤷‍♂️

The comment is present in the following two locations:

printf-compat/README.md

Lines 22 to 25 in a6f6aad

	- Likewise, if you're using `wasm32-unknown-unknown` instead of emscripten
	(as wasm-bindgen is only compatible with the former), you have no libc. If
	you want to interface with a C library, you'll have to do it all yourself.
	With this crate, that turns into 5 lines instead of hundreds for `printf`.

printf-compat/src/lib.rs

Lines 17 to 20 in a6f6aad

	//! - Likewise, if you're using `wasm32-unknown-unknown` instead of emscripten
	//! (as wasm-bindgen is only compatible with the former), you have no libc. If
	//! you want to interface with a C library, you'll have to do it all yourself.
	//! With this crate, that turns into 5 lines instead of hundreds for `printf`.

[nicholasbishop]

I'm not particularly familiar with the wasm stuff either, but I note that these target strings are different: wasm32-unknown-emscripten vs wasm32-unknown-unknown. Is the latter target also supported by wasm-bindgen now?

[polarathene]

Is the latter target also supported by wasm-bindgen now?

Yes, check the link I provided. Supported since March 2026.

I don't directly use printf-compat (only exposure to it is via eyra/c-scape crates). I don't have much experience with these wasm targets nor wasm-bindgen, so I am not sure what to suggest here other than the README snippet is either outdated or it's content was not well-written regarding the wasm-bindgen + emscripten association.

Presumably providing your own printf() by using the printf-compat crate doesn't make sense when building for the emscripten target? (given it can provide it's own libc with printf()) 😅

---

Additional Context

I'm not particularly familiar with the wasm stuff either

• wasm32-unknown-unknown: Basic/minimal WASM profile, it has a limited subset of the std crate (eg: println!/eprintln! are no-op).
  • This target can be run outside of the browser, but wasm-bindgen provides JS bindings for bridging stdout/stderr to JS for example which would work in the browser or any other JS runtime like NodeJS.
  • The libc crate doesn't have support for this target, so various crates that would require compiling C/C++ code would fail, however if the C/C++ code doesn't lean on that libc crate you're fine. So that remains relevant for printf-compat AFAIK.
  • Uses dlmalloc-rs crate for the global allocator.
• wasm32-unknown-emscripten:
  • JS specific with musl libc adapted to browser web APIs. WASM is deployed with with supporting JS in the browser for that additional functionality. This includes graphics rendering (SDL being a notable project).
  • Compatible with crates that compile C/C++ or use libc crate IIRC.
  • Uses dlmalloc (C) or optionally mimalloc for the global allocator.
• WASI targets:
  • A more modern target than emscripten that can run outside of a browser (can also run in a browser with WASI polyfills or related JS runtime integration via jco).
  • WASI extends the WASM spec to bridge more system interfaces, but like the prior targets some support like multi-threading is still iffy IIRC (WASI recently released 0.3.0 in June 2026, they're actively improving the threading support now).
  • Like the emscripten target println!/eprintln should work with stdout/stderr by default. It also uses musl as it's base libc via wasi-libc which makes modifications for the WASI cross-platform spec and relies upon a host runtime (which as a separate host native program will use it's own libc) to execute the WASM program for bridging the WASI spec to the host system OS. Similar to emscripten I believe this target is also compatible with the libc crate.
  • printf-compat would work like usual AFAIK, allowing Rust code to provide printf that could be used from foreign code.
  • The WASI target(s) in Rust tend to also get used as an alternative workaround for wasm32-unknown-unknown when needing libc crate compatibility, or compiling C/C++ code that depends upon libc stdlib headers IIRC. So long as none of that compilation involves anything dependent upon the WASI spec itself, the .wasm produced is apparently compatible as plain WASM (I'm not sure if that's the same for emscripten, but the impression I have thus far is it might not be, or something else about it's toolchain is undesirable).
  • dlmalloc (C) is used as the global allocator, so unlike wasm32-unknown-unknown it delegates to libc (like standard rust targets normally would) and wasi-libc is providing malloc with dlmalloc like emscripten also does. There may be other minor differences like this between the targets.

---

Is the latter target also supported by wasm-bindgen now?

Yes, see the link I provided earlier in the issue description.

It's in the projects changelog since March 2026, although I'm not sure what the status of that support is exactly (I've yet to use wasm-bindgen, I'm still getting familiar with the targets and ecosystem). There does seem to be some ongoing work refining it.

WASI was supported by wasm-bindgen in the past, but I think may have been unintentional and was dropped at some point as the original project author (whom wasn't too familiar with WASI as they were WASM) did not see much sense in it (I don't think WASI had progressed to the component model at that point, nor was something like jco available?) and another motivating factor I think was a user bug report where the presence of wasm-bindgen for WASI targets was breaking compatibility of WASI .wasm with the runtime wasmer, but that might have been an issue related to WASM having a non-standard C ABI prior to Rust 1.89 (might have only applied to wasm32-unknown-unknown, I'd have to check).

---

Sorry that those are not the most clearest of answers 😓

It would seem that:

• wasm32-unknown-unknown is fairly standard / popular as a target, with a notable improvement for Rust 1.89 switching to a standards compliant C ABI.
• emscripten is a rather old (though still actively developed) variant for supporting C/C++ to WASM with a libc bridging JS and browser APIs (notably with coverage for UI which the WASI spec itself has not yet expanded to), so it's still relevant for some projects but strictly only works with JS (possibly only the browser).
• WASI seems to be a more official standard vs emscripten that extends WASM capabilities and integrates with host environments better at runtime, providing a more capable cross-platform single binary (host specific runtime aside).
• As WASI matures and addresses the feature parity difference, emscripten may eventually lose relevance and there'd be a transition. Unclear if wasm-bindgen has relevance for the WASI target (other than those that want to use standard wasm32-unknown-unknown but use WASI as workaround for wasi-libc toolchain to successfully compile and deploy to the browser environment instead of using emscripten for some reason), it may still be valid if deploying WASI to the browser with jco or similar (providing runtime support).

[nicholasbishop]

Yes, check the link I provided. Supported since March 2026.

Just double checking, the link you mean is this one? wasm-bindgen/wasm-bindgen#5237
That link does not mention wasm32-unknown-unknown as far as I can see.

Anyway, it probably doesn't matter. We can remove that third bullet point from the list of use cases for printf-compat, as it's basically the same as the one before it.

[polarathene]

@lights0123 could perhaps chime in as they authored the wasm-bindgen/emscripten note back in Nov 2020 (initial commit of project).

AI suggested revision based on assumption that the note was phrased poorly

Gemini AI suggests the following:

Conflating two separate problems

The author baked two unrelated technical hurdles into a single sentence:

• Hurdle A (wasm32-unknown-unknown lacks a libc): This is true. If you compile a C library to wasm32-unknown-unknown, it will look for printf and fail to find it.
• Hurdle B (Choosing a JS integration framework): Bringing wasm-bindgen into a project is about generating JavaScript/WebAssembly glue bindings. It has fundamentally nothing to do with whether your target environment has a C standard library (libc).

A developer reading that README naturally thinks: "Does wasm-bindgen force me to use wasm32-unknown-unknown, which then forces me to manually fix printf using this crate?"

How it should read

A clearer, less confusing way for the author to phrase that would simply be:

"If you are targeting a bare-metal environment like wasm32-unknown-unknown that lacks a standard C library (libc), you won't have a built-in printf function. If you are trying to interface with a C library there, you would normally have to write hundreds of lines to handle C's va_list. With this crate, that turns into just a few lines."

Dropping the unnecessary and confusing reference to wasm-bindgen entirely would make the explanation much sharper and accurate.

[nicholasbishop]

Please don't just post the output of an LLM in a github issue -- I can run those myself if I want to :)

[polarathene]

Yes, check the link I provided. Supported since March 2026.

Just double checking, the link you mean is this one? wasm-bindgen/wasm-bindgen#5237 That link does not mention wasm32-unknown-unknown as far as I can see.

Oh sorry, I got that mixed up 😓

wasm-bindgen has always supported the wasm32-unknown-unknown target.

---

Anyway, it probably doesn't matter. We can remove that third bullet point from the list of use cases for printf-compat, as it's basically the same as the one before it.

That makes sense 👍 I was mostly confused about was meant by the emscripten + wasm-bindgen statement, and the fact that it was now something that was supported.

[lights0123]

I made this library for this project, where I was linking C and Rust together for WASM (which technically was unsupported until recently, but it worked anyways 🤷‍♂️). That C library called a user-supplied version of printf. Because I was targeting wasm32-unknown-unknown, I couldn't just provide a little wrapper around the real vsprintf as I didn't have a libc implementing it.

If I was targeting emscripten instead (which was not supported by wasm-bindgen at the time), then I could just use their libc's implementation.