Hacker News Reader

Comment by littlestymaar | Hacker News Reader

Why is it written in C++, when Google made Wuffs[1] for this exact purpose?

This is pure speculation, but I'm presuming Wuffs is not the easiest language to use during the research phase, but more of a thing you would implement a format in once it has stabilized. And this is freshly published research.

Probably would be a good idea to get a port though, if possible, improving both safety and performance sounds like a win to me.

Yeah, you're right. It's not as easy to write Wuffs code during the research phase, since you don't just have to write the code, you also have to help the compiler prove that the code is safe, and sometimes refactor the code to make that tractable.

Wuffs doesn't support global variables, but when I'm writing my own research phase code, sometimes I like to just tweak some global state (without checking the code in) just to get some experimental data: hey, how do the numbers change if I disable the blahblah phase when the such-and-such condition (best evaluated in some other part of the code) holds?

Also, part of Wuffs' safety story is that Wuffs code cannot make any syscalls at all, which implies that it cannot allocate or free memory, or call printf. Wuffs is a language for writing libraries, not whole programs, and the library caller (not callee) is responsible for e.g. allocating pixel buffers. That also makes it harder to use during the research phase.

Wuffs is for the exact _opposite_ purpose (decoding). It can do simple encoding once you know what bits to put in the file, but a JPEG encoder contains a lot of nontrivial machinery that does not fit well into Wuffs.

(I work at Google, but have nothing to do with Jpegli or Wuffs)

The first paragraph in Wuffs's README explicitly states that it's good for both encoding and decoding?

No, it states that wrangling _can be_ encoding. It does not in any way state that Wuffs is actually _good_ for it at the current stage, and I do not know of any nontrivial encoder built with Wuffs, ever. (In contrast, there are 18 example decoders included with Wuffs. I assume you don't count the checksum functions as encoding.)

Encoding is definitely in Wuffs' long term objectives (it's issue #2 and literally in its doc/roadmap.md file). It's just that decoding has been a higher priority. It's also a simpler problem. There's often only one valid decoding for any given input.

Decoding takes a compressed image file as input, which have complicated formats. Roughly speaking, encoding just takes a width x height x 4 pixel buffer, with very regular structure. It's much easier to hide something malicious in a complicated format.

Higher priority means that, when deciding whether to work on a Wuffs PNG encoder or a Wuffs JPEG decoder next, when neither existed at the time, I chose to have more decoders.

(I work at Google, and am the Wuffs author, but have nothing to do with Jpegli. Google is indeed a big company.)

Thanks for the answer!

Google is a big company.

this is a valid question why is it being downvoted?

Maybe because the hailing for yet another "safe" language starts to feel kinda repetitive?

Java, C#, Go, Rust, Python, modern C++ with smartpointer,...

I mean a concepts for handling files in a safe way are an awesome (and really needed) thing, but inventing a whole new programming language around a single task (even if it's just a transpiler to c)?

One of the advantages with wuffs is that it compiles to C and wuffs-the-library is distributed as C code that is easy to integrate with an existing C or C++ project without having to incorporate new toolchains.

> Maybe because the hailing for yet another "safe" language starts to feel kinda repetitive?

Ah yeah, because the endless stream of exploits and “new CVE allows for zero-click RCE, please update ASAP” doesn't feel repetitive?

> I mean a concepts for handling files in a safe way are an awesome (and really needed) thing, but inventing a whole new programming language around a single task (even if it's just a transpiler to c)?

It's a “single task” in the same way “writing compilers” is a single task. And like we're happy that LLVM IR exists, having a language dedicated to writing codecs (of which there are dozens) is a worthwhile goal, especially since they are both security critical and have stringent performance needs for which existing languages (be it managed languages or Rust) aren't good enough.

Reply on news.ycombinator.com