4 ms·

I have no experience with media encoders/decoders but I have a feeling that you have no choice then work with raw bytes and not with high level wrappers becaus

I have no experience with media encoders/decoders but I have a feeling that you have no choice then work with raw bytes and not with high level wrappers because of speed, so I bet you will find similar issues in other languages if anyone wrote such a library in something else then C.

sitzkrieg 3y ago
yea this is where i was gunna go, agreed
- lolinder 3y ago
  And did you miss all the reasons people gave why that interpretation is itself naive? C's unchecked memory access is the problem, and modern languages have solved it while still allowing writing byte-level code. Claiming that any other language that allows reading and writing raw bytes would have the same issue simply shows you do not understand the problem or the many solutions already available.
  - sitzkrieg 3y ago
    it is also possible to write secure c code, as it is in any other language.
lolinder 3y ago
Working with raw bytes is not the problem, out-of-bounds writes is the problem. A language can allow you to read and write raw bytes while still ensuring (either statically or at runtime) that you aren't able to access memory that isn't yours.
btilly 3y ago
Rust was created for the purpose of having a way to write such code while avoiding this class of issue. And the original use case was specifically to make it easier to make browsers more secure. It's just that there is a lot of legacy code, and the migration to languages like Rust will take a long time.
pornel 3y ago
This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower. Codecs have a lot of "glue" code handling configuration, I/O, and other stuff besides their most performance sensitive bit-pushing loops. But this safe-or-fast dilemma has been mostly solved with Rust (and Wuffs). I am writing codecs in Rust. Rust has many zero-cost abstractions (high level wrappers that get inlined, and compiled for specific types and values you use them with, and it gets optimized as concrete low-level code). This allows writing a lot performance-sensitive code using safe Rust. For example, you don't get redundant bounds checks if you use iterators, and despite being high-level abstraction with chains of iterators and closures, they compile to simple loops, and may even get vectorized (even more so than C, thanks to Rust's stronger no-aliasing and immutability guarantees). When you need something more adventurous, you can dress it in a safe (compiler-verified) higher-level abstraction on top of minimal amount of unsafe code. Even though the underlying unsafe code is as unsafe as C, making a small component out of it helps to review/test/fuzz it in isolation against its interface, rather than test it as part of a complex algorithm.

sitzkrieg 3y ago

yea this is where i was gunna go, agreed

lolinder 3y ago
And did you miss all the reasons people gave why that interpretation is itself naive? C's unchecked memory access is the problem, and modern languages have solved it while still allowing writing byte-level code. Claiming that any other language that allows reading and writing raw bytes would have the same issue simply shows you do not understand the problem or the many solutions already available.
- sitzkrieg 3y ago
  it is also possible to write secure c code, as it is in any other language.

lolinder 3y ago

Working with raw bytes is not the problem, out-of-bounds writes is the problem. A language can allow you to read and write raw bytes while still ensuring (either statically or at runtime) that you aren't able to access memory that isn't yours.

btilly 3y ago

Rust was created for the purpose of having a way to write such code while avoiding this class of issue. And the original use case was specifically to make it easier to make browsers more secure. It's just that there is a lot of legacy code, and the migration to languages like Rust will take a long time.

pornel 3y ago

This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower. Codecs have a lot of "glue" code handling configuration, I/O, and other stuff besides their most performance sensitive bit-pushing loops. But this safe-or-fast dilemma has been mostly solved with Rust (and Wuffs). I am writing codecs in Rust. Rust has many zero-cost abstractions (high level wrappers that get inlined, and compiled for specific types and values you use them with, and it gets optimized as concrete low-level code). This allows writing a lot performance-sensitive code using safe Rust. For example, you don't get redundant bounds checks if you use iterators, and despite being high-level abstraction with chains of iterators and closures, they compile to simple loops, and may even get vectorized (even more so than C, thanks to Rust's stronger no-aliasing and immutability guarantees). When you need something more adventurous, you can dress it in a safe (compiler-verified) higher-level abstraction on top of minimal amount of unsafe code. Even though the underlying unsafe code is as unsafe as C, making a small component out of it helps to review/test/fuzz it in isolation against its interface, rather than test it as part of a complex algorithm.