[MutableLambda]

Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.

[jsheard]

That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works.

I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.

[philistine]

If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!

[chimeracoder]

> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen.

At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.

[spookie]

Well, the first public implementation dates to 2020. And, the Cpp choice is obvious, simpler integration with the majority of existing image processing libs, tools and utilities. Not to mention GUI toolkits.

Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!

[SoKamil]

> any substantial (non-degenerative)

Why this quality poses security issues?

[izacus]

And yet whole of HN is VERY VERY angry because Google won't ship that pile of C++ into most popular software (and app framework) in the world.