1. Can be compiled without assembly, and I believe SIMD can be written safely if you think about what it is actually doing
2. The only dependency is zerocopy which is used in a lot of major projects considered to be safe
There are cases for which Fil-C makes plenty of sense but this isn't one of them.
If you can't afford WUFFS then this Rust is the sensible choice. There aren't going to be any real cases where you can afford Fil-C but you can't afford WUFFS.
A WUFFS codec is obviously going to be a lot faster than Fil-C for similar development effort but it's also going to be entirely safe at compile time whereas in Fil-C too bad any mistakes will get caught in production as denials of service.
The Rust is a compromise in that regard, it's not going to catch everything WUFFS would catch during compilation but it will catch a lot more than Fil-C
> any real cases where you can afford Fil-C but you can’t afford WUFFS
Anytime you already have the C or C++ code but not the WUFFS.
The main use case for the Fil-C build of webp is my memory safe web browser, which is built entirely using Fil-C (including all dependencies).
> WUFFS codec is obviously going to be a lot faster than Fil-C for similar development effort
For greater development effort. Fil-C is just C, so WUFFS is only comparable effort if that’s the only version of the codec you ever write, and in the unlikely case you are as productive in WUFFS as you would have been in C.
> it will catch a lot more than Fil-C
Like what?
Fil-C catches not just the bugs in your codec but any transitive misuse of it from other C or C++ code. So, while you might be able to pick out things Rust or WUFFS catch that Fil-C doesn’t, I can easily pick out things that Fil-C catches that nothing else can.
> Anytime you already have the C or C++ code but not the WUFFS.
But we literally do already have WebP for WUFFS.
> Like what?
Take a recent (September) double-free in the C codec, it's easy to write that in C. We have a Thing, we sometimes make an alias to the Thing, and then later we free both the alias and the original Thing. In Rust when you try to write this the compiler is unhappy. We can either have the same realisation which led to that being fixed (we do not need this alias, it should not be created) -- which I'd say is likely for a competent Rust programmer or we can clone the Thing, and then free both the clone and original, which is not a bug unlike the C library but is a waste of performance.
> But we literally do already have WebP for WUFFS.
This comes down to how strong your claim is, and what point you're trying to make.
If you're saying that compiling codecs in Fil-C is not a good use of Fil-C in general, then that's wrong, because not all codecs have a WUFFS version.
If you're saying that compiling WebP with Fil-C is not a good use of Fil-C because there's a WUFFS version, then that's also wrong, because I can't use the WUFFS version in a fully memory-safe web browser, since WUFFS doesn't support Fil-ABI and nobody has written a browser where the whole transitive closure of everything that the browser uses is WUFFS or some other safe language.
On the other hand, that is possible with Fil-C. (I'm posting this comment using a memory safe browser built with Fil-C, which has WebP built with Fil-C as well as everything else down to the libc/libc++ layer built with Fil-C.)
> double-free
Double-frees are deterministic panics in Fil-C. So yeah, Fil-C catches that, and any other memroy safety violation that could be used to achieve weird execution
> Double-frees are deterministic panics in Fil-C
What does "deterministic panic" mean here? It sounds like that's a runtime panic, but the whole point of the paragraph you were quoting is compile time safety.
WUFFS is able to guarantee safety of the codec at compile time.
Rust is able to offer only some of its guarantees at compile time, and the rest are delivered at runtime.
Fil-C delivers almost all of its safety guarantees at runtime.
pizlonator · · focus · HN ↗
This is great but it’s got caveats:
- assembly code. They may have been careful but it’s an escape hatch
- if it has basically any dependencies then those are likely to transitively pull in more unsafe code
computerbuster · · focus · HN ↗
tialaramex · · focus · HN ↗
If you can't afford WUFFS then this Rust is the sensible choice. There aren't going to be any real cases where you can afford Fil-C but you can't afford WUFFS.
A WUFFS codec is obviously going to be a lot faster than Fil-C for similar development effort but it's also going to be entirely safe at compile time whereas in Fil-C too bad any mistakes will get caught in production as denials of service.
The Rust is a compromise in that regard, it's not going to catch everything WUFFS would catch during compilation but it will catch a lot more than Fil-C
pizlonator · · focus · HN ↗
Anytime you already have the C or C++ code but not the WUFFS.
The main use case for the Fil-C build of webp is my memory safe web browser, which is built entirely using Fil-C (including all dependencies).
> WUFFS codec is obviously going to be a lot faster than Fil-C for similar development effort
For greater development effort. Fil-C is just C, so WUFFS is only comparable effort if that’s the only version of the codec you ever write, and in the unlikely case you are as productive in WUFFS as you would have been in C.
> it will catch a lot more than Fil-C
Like what?
Fil-C catches not just the bugs in your codec but any transitive misuse of it from other C or C++ code. So, while you might be able to pick out things Rust or WUFFS catch that Fil-C doesn’t, I can easily pick out things that Fil-C catches that nothing else can.
tialaramex · · focus · HN ↗
But we literally do already have WebP for WUFFS.
> Like what?
Take a recent (September) double-free in the C codec, it's easy to write that in C. We have a Thing, we sometimes make an alias to the Thing, and then later we free both the alias and the original Thing. In Rust when you try to write this the compiler is unhappy. We can either have the same realisation which led to that being fixed (we do not need this alias, it should not be created) -- which I'd say is likely for a competent Rust programmer or we can clone the Thing, and then free both the clone and original, which is not a bug unlike the C library but is a waste of performance.
pizlonator · · focus · HN ↗
This comes down to how strong your claim is, and what point you're trying to make.
If you're saying that compiling codecs in Fil-C is not a good use of Fil-C in general, then that's wrong, because not all codecs have a WUFFS version.
If you're saying that compiling WebP with Fil-C is not a good use of Fil-C because there's a WUFFS version, then that's also wrong, because I can't use the WUFFS version in a fully memory-safe web browser, since WUFFS doesn't support Fil-ABI and nobody has written a browser where the whole transitive closure of everything that the browser uses is WUFFS or some other safe language.
On the other hand, that is possible with Fil-C. (I'm posting this comment using a memory safe browser built with Fil-C, which has WebP built with Fil-C as well as everything else down to the libc/libc++ layer built with Fil-C.)
> double-free
Double-frees are deterministic panics in Fil-C. So yeah, Fil-C catches that, and any other memroy safety violation that could be used to achieve weird execution
tialaramex · · focus · HN ↗
What does "deterministic panic" mean here? It sounds like that's a runtime panic, but the whole point of the paragraph you were quoting is compile time safety.
WUFFS is able to guarantee safety of the codec at compile time.
Rust is able to offer only some of its guarantees at compile time, and the rest are delivered at runtime.
Fil-C delivers almost all of its safety guarantees at runtime.
pizlonator · · focus · HN ↗