3 ms·

Why is it written in C++, when Google made Wuffs[1] for this exact purpose? [1]: https://github.com/google/wuffs https://github.com/google/wuffs

ramrunner0xff 3y ago
this is a valid question why is it being downvoted?
- SunlitCat 3y ago
  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)?
  - vinkelhake 3y ago
    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.
  - littlestymaar 3y ago
    > 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.
deleted 3y ago
[deleted]
vanderZwan 3y ago
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.
- nigeltao 3y ago
  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.
Blackthorn 3y ago
Google is a big company.
Sesse__ 3y ago
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)
- Hackbraten 3y ago
  The first paragraph in Wuffs's README explicitly states that it's good for both encoding and decoding?
  - Sesse__ 3y ago
    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.)
- nigeltao 3y ago
  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.)
  - littlestymaar 3y ago
    Thanks for the answer!

ramrunner0xff 3y ago

this is a valid question why is it being downvoted?

SunlitCat 3y ago
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)?
- vinkelhake 3y ago
  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.
- littlestymaar 3y ago
  > 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.

deleted 3y ago

[deleted]

vanderZwan 3y ago

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.

nigeltao 3y ago
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.

Blackthorn 3y ago

Google is a big company.

Sesse__ 3y ago

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)

Hackbraten 3y ago
The first paragraph in Wuffs's README explicitly states that it's good for both encoding and decoding?
- Sesse__ 3y ago
  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.)
nigeltao 3y ago
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.)
- littlestymaar 3y ago
  Thanks for the answer!