An open-source entry in TopGit's GitHub warehouse: google/wuffs, 4.8k stars, C. Wrangling Untrusted File Formats Safely
Snapshot summary built from the project's own GitHub metadata — there's no written TopGit review yet. The page will update automatically when a full review is published.
WHY NO REVIEW YET
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then — see the READ ME tab for the original README in full.
Wuffs is a memory-safe programming language (and a standard library
written in that language) for Wrangling Untrusted File Formats Safely.
Wrangling includes parsing, decoding and encoding. Example file formats include
images, audio, video, fonts and compressed archives.
It is "ridiculously
fast".
Per its benchmarks and other linked-to blog posts:
It can decode bzip2 1.3x faster than /usr/bin/bzcat
(C).
It can decode deflate up to 1.4x faster than zlib-the-library (C).
It can decode GIF 2x-6x faster than "giflib" (C), "image/gif" (Go) and
"gif" (Rust).
It can decode PNG 1.2x-2.7x faster than "libpng" (C), "image/png" (Go) and
"png"
(Rust).
Goals and Non-Goals
Wuffs' goal is to produce software libraries that are as safe as Go or Rust,
roughly speaking, but as fast as C, and that can be used anywhere C libraries
are used. This includes very large C/C++ projects, such as popular web browsers
and operating systems (using that term to include desktop and mobile user
interfaces, not just the kernel).
Wuffs the Library is available as
transpiled C code. Other C/C++ projects can use that library without
requiring the Wuffs the Language toolchain.
Those projects can use Wuffs the Library like using any other third party C
library. It's just not hand-written C.
However, unlike hand-written C, Wuffs the Language is safe with respect to
buffer overflows, integer arithmetic overflows and null pointer dereferences. A
key difference between Wuffs and other memory-safe languages is that all such
checks are done at compile time, not at run time. If it compiles, it is safe,
with respect to those three bug classes.
The trade-off in aiming for both safety and speed is that Wuffs programs take
longer for a programmer to write, as they have to explicitly annotate their
programs with proofs of safety. A statement like x += 1 unsurprisingly
means to increment the variable x by 1. However, in Wuffs, such a statement
is a compile time error unless the compiler can also prove that x is not the
maximal value of x's type (e.g. x is not 255 if x is a base.u8), as
the increment would otherwise overflow. Similarly, an integer arithmetic
expression like x / y is a compile time error unless the compiler can also
prove that y is not zero.
Hermeticity
Wuffs is not a general purpose programming language. It is for writing
libraries, not programs. Wuffs code is hermetic
and can only compute (e.g. convert "compressed bytes" to "decompressed bytes").
It cannot make any syscalls (e.g. it has no ambient authority to read your
files), implying that it cannot allocate or free memory (and is therefore
trivially safe against things like memory leaks, use-after-frees and
double-frees).
It produces Sans I/O style libraries (but C
libraries, not Python), meaning that they are agnostic to 'function
colors'.
They can be combined with synchronous or asynchronous I/O, as the library
caller (not library implementation) is responsible for the actual I/O.
The idea isn't to write your whole program in Wuffs, only the parts that are
both performance-conscious and security-conscious. For example, while
technically possible, it is unlikely that a Wuffs compiler would be worth
writing entirely in Wuffs.
What Does Wuffs Code Look Like?
The /std/lzw/decode_lzw.wuffs file is a good
example. The Wuffs the Language document has more
information on how it differs from other languages in the C family.
What Does Compile Time Checking Look Like?
For example, making this one-line edit to the LZW codec leads to a compile time
error. wuffs gen fails to generate the C code, i.e. fails to compile
(transpile) the Wuffs code to C code:
diff --git a/std/lzw/decode_lzw.wuffs b/std/lzw/decode_lzw.wuffs
index f878c5e..f10dcee 100644
--- a/std/lzw/decode_lzw.wuffs
+++ b/std/lzw/decode_lzw.wuffs
@@ -98,7 +98,7 @@ pub func lzw_decoder.decode?(dst ptr buf1, src ptr buf1, src_final bool)() {
in.dst.write?(x:s)
if use_save_code {
- this.suffixes[save_code] = c as u8
+ this.suffixes[save_code] = (c + 1) as u8
this.prefixes[save_code] = prev_code as u16
}
$ wuffs gen std/gif
check: expression "(c + 1) as u8" bounds [1 ..= 256] is not within bounds [0 ..= 255] at
/home/n/go/src/github.com/google/wuffs/std/lzw/decode_lzw.wuffs:101. Facts:
n_bits < 8
c < 256
this.stack[s] == (c as u8)
use_save_code
In comparison, this two-line edit will compile (but the "does it decode GIF
correctly" tests then fail):
diff --git a/std/lzw/decode_lzw.wuffs b/std/lzw/decode_lzw.wuffs
index f878c5e..b43443d 100644
--- a/std/lzw/decode_lzw.wuffs
+++ b/std/lzw/decode_lzw.wuffs
@@ -97,8 +97,8 @@ pub func lzw_decoder.decode?(dst ptr buf1, src ptr buf1, src_final bool)() {
// type checking, bounds checking and code generation for it).
in.dst.write?(x:s)
- if use_save_code {
- this.suffixes[save_code] = c as u8
+ if use_save_code and (c < 200) {
+ this.suffixes[save_code] = (c + 1) as u8
this.prefixes[save_code] = prev_code as u16
}
lang holds the Go libraries that implement Wuffs the Language: tokenizer,
AST, parser, renderer, etc. The Wuffs tools are written in Go, but as
mentioned above, Wuffs transpiles to C code, and Go is not necessarily
involved if all you want is to use the C edition of Wuffs.
lib holds other Go libraries, not specific to Wuffs the Language per se.
internal holds internal implementation details, as per Go's internal
packages convention.
cmd holds Wuffs the Language' command line tools, also written in Go.
std holds Wuffs the Library's code.
release holds the releases (e.g. in their C form) of Wuffs the Library.
test holds the regular tests for Wuffs the Library.
fuzz holds the fuzz tests for Wuffs the Library.
script holds miscellaneous utility programs.
doc holds documentation.
example holds example programs for Wuffs the Library.
hello-wuffs-c holds an example program for Wuffs the Language.
Building
See the BUILD instructions.
Documentation
Getting Started. Start here if you want to
play but aren't sure how (and BUILD doesn't help).
Background.
Benchmarks.
Binary Size.
Changelog.
Glossary.
Related Work.
Roadmap.
Wuffs the Language overview.
Wuffs the Library overview and see also API
categories.
The Note directory also contains various short articles.
Non-C/C++ Languages
dev0x13/pywuffs holds Python bindings
for Wuffs the Library.
Bindings for Go, Rust and other languages are tracked as issue
#38.
Status
Version 0.3 (April 2023) is the latest stable version. Stable means that
its API won't change any further, but being a "version 0.x" means that:
It will not have long term support.
Newer versions make no promises about compatibility.
The compiler undoubtedly has bugs. Assertion checking needs more rigor,
especially around side effects and aliasing, and being sufficiently well
specified to allow alternative implementations. Lots of detail needs work, but
the broad brushstrokes are there.
Nonetheless, Wuffs' GIF decoder has shipped in the Google Chrome web browser
since June
2021
(milestone M93). See also the "ridiculously
fast" tweet already
mentioned above.
Discussion
The mailing list is at
https://groups.google.com/forum/#!forum/wuffs.
Contributing
The CONTRIBUTING.md file contains instructions on how to
file the Contributor License Agreement before sending any pull requests (PRs).
Of course, if you're new to the project, it's usually best to discuss any
proposals and reach consensus before sending your first PR.
Source code is auto-formatted.
License
This software is distributed under the terms of both the MIT license and the
Apache License (Version 2.0).
See LICENSE for details.
Disclaimer
This is not an official Google product, it is just code that happens to be
owned by Google.
Mascot
Tony is an arse-kicking wombat who loves playing
full-forward and hates buffer
overflows.
No homepage URL was recorded for google/wuffs in TopGit's last sync. The README tab above frequently contains screenshots and demo links, or check the repository description on GitHub.
How active is development on google/wuffs?
The most recent commit recorded on google/wuffs was 12 days ago, based on the GitHub push timestamp. The repository has 144 forks — one of the better signals of community interest.
Is google/wuffs open source?
TopGit's metadata for google/wuffs does not record a license. Most public repositories on GitHub ARE open source, but the exact terms vary — verify by opening the LICENSE file directly.
What topics is google/wuffs associated with?
GitHub's repository topics for google/wuffs: "codec", "memory-safety", "parsing", "programming-language". TopGit's editorial category is open-source.
Where do I read more about google/wuffs?
This TopGit page is a snapshot — the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/google/wuffs is the definitive source.
Read full README in the tab above.
Want a second opinion on wuffs?
Ask an AI that can read this page — one click and you get its take on wuffs.