Giving Rust a chance for in-kernel codecs

Posted Apr 27, 2024 16:44 UTC (Sat) by atnot (guest, #124910)
In reply to: Giving Rust a chance for in-kernel codecs by dvdeug
Parent article: Giving Rust a chance for in-kernel codecs

I'd say this is basically already the case for rust with e.g. capable iterators that remove almost every case where you'd normally use indexing in languages without them. Of course that doesn't help you when you do for whatever reason need to for whatever reason, but to be honest I think most of my codebases contain few if any instances of array indexing.

Giving Rust a chance for in-kernel codecs

Posted Apr 29, 2024 20:40 UTC (Mon) by gspr (subscriber, #91542) [Link] (1 responses)

Since multimedia codecs are the focus of this thread, I think they constitute a type of code where explicit indexing very much remains necessary. It's often not possible to express things like "add the red value of this pixel plus c times the blue value of the pixel k rows directly above it" using iterators, let alone iterators where the compiler can automatically elide bounds checking.

Giving Rust a chance for in-kernel codecs

Posted Apr 29, 2024 23:19 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

But it certainly _is_ possible to develop a language where a machine tool can follow along with the discrete maths needed to see that we're in bounds when we do this, or point to where our code doesn't do what we thought it did (e.g. it's mandatory for videos in our encoding to have width multiple of 16, and so we didn't check that but our code assumes it's true, leaving a gap for anybody to just lie)

We only need to: Develop that language (for conventional software codecs it exists, it's named WUFFS) and teach the handful of people who write new codecs how to use this purpose made language and then sit back and enjoy the high performance totally safe results.