Wuffs is a memory-safe programming language, with compiler-enforced bounds checking against buffer overflows and nullptr dereferences. By default, it also prevents uninitialized reads, although some zero-initialization is optional, for additional performance.
A deliberate constraint in the Wuffs language is that struct fields cannot store any pointers to dynamically allocated memory, only to statically allocated error messages (a base.status). When a Wuffs decompressor reads from or writes to a buffer, that buffer has to be passed on every call, instead of being passed once during initialization and saved to a field. There is no ambiguity about whether the caller or callee should free some memory, even when encountering an error. It's always caller-owned and callee-borrowed.
Wuffs is also trivially safe against things like memory leaks, use-after-frees and double-frees because Wuffs code doesn't even have the capability to allocate or free memory, other than its transpiled-to-C form providing wuffs_foo__bar__alloc convenience functions to set up before processing a single byte of input. Wuffs is certainly less powerful than other programming languages, but with less power comes easier proof of safety. Still, Wuffs is not a toy language and the example programs do real work.
Wuffs is a language for writing libraries, and complete programs require combining Wuffs with another programming language. The obvious example is the C/C++ programming language, but it could be something else. For argument‘s sake, let’s call it “PL”.
If “PL” is not memory-safe, then clearly “Wuffs + PL” is also not memory-safe overall. Nonetheless, “Wuffs + PL” is still safer than “just PL”, especially if the Wuffs parts are the only ones that are in direct contact with untrusted (and possibly maliciously crafted) inputs. There is value in structuring a program so that the bulk of the computation happens in Wuffs (memory-safe even for performant, relatively complicated code) and the memory-unsafe configuration, outside of inner loops, can be in relatively simple code that prioritizes readability over raw performance.
The inability for Wuffs libraries to allocate memory means that their APIs may look unfamiliar at first. For example, there isn't a single “decode a JPEG” function. Instead, image decoding typically involves multiple steps:
For compression decoding, a fixed size buffer can be re-used, combining I/O buffers with coroutines. The example/zcat program can decompress arbitrarily large input using static buffers, without ever calling malloc. Indeed, on Linux, that program self-imposes a SECCOMP_MODE_STRICT sandbox, prohibiting dynamic memory allocation (amongst many other powerful but dangerous things) at the kernel level. The example/jsonptr program, which parses and filters JSON, is another example that does useful work within a strict sandbox.
Alternatively, Wuffs-the-library's auxiliary code, augmenting the Wuffs-the-language code with hand-written C++ helpers, provides higher level (allocating) APIs, albeit with several trade-offs.
Unless otherwise noted, a Wuffs object is not thread-safe, but Wuffs code also lacks the capability to create, destroy or otherwise manage threads. There is also no global mutable state, so two separate Wuffs objects are safe to use from two separate threads.