Transitioning code to Rust

[rocky]

This space is for extending libcdio to Rust and, in the longer term, possibly transitioning the code to.

[rocky]

See

• build: Add Rust #49 (comment)
• build: Add Rust #49 (comment)
• build: Add Rust #49 (comment)
• build: Add Rust #49 (comment)
• build: Add Rust #49 (comment)
• build: Add Rust #49 (comment)

[rocky]

First of all, thanks to @pbatard and @enzo1982 for the information on how libcdio is currently used in Rufus and fre:ac.

I'm aware of these, but I confess that I didn't understand the extent of its use or how embedded it is.

It is important, as things move forward, not to cause a burden on these projects. If that happens, let me know and I'll see what we can do.

I am okay with doing parallel work in C. In fact, on several other projects I work on, I have to do the same. (For example, changes to a bash debugger for one version of bash might have to get translated to another version or even a debugger in zsh or ksh; same thing for a GNU Make fork. So, while others may find this busy-work, it's definitely an activity that I am used to — until we can transition everything.

With respect to the thought that C will be around in 30 years, while that may be true, I won't be around in 30 years. And possibly some of you won't either. The number of people interested in C as opposed to other languages, which are more like Rust (typestate or strongly typed languages). Personally, one of my biggest annoyances with libcdio has been the CVEs found and logged purely due to problems in memory management and buffer overflows.

Let's face it, activity in libcdio hasn't been all that large. Stagnation is death. Personally, I'd like all C code I've written to be redone in a more modern language, and right now Rust seems to be the best choice. My thought or hope was that libcdio would be the easiest and smallest-sized project. Replacing GNU make, or its forked version, remake, is much tougher.

This summer, I have the opportunity to get help in this endeavor. I wish we could have had this discussion sooner.

[pbatard]

I'm going to try to keep this short, so here are the points I would make.

1. Projects that support multiple toolchains and OSes are ill-suited to speed up the transition to Rust. This is currently better left to projects that are designed for a single OS and are designed around a very limited number of toolchains. You just have to look at the Actions workflows we currently have. This is pretty much a reiteration of the point I was making earlier: Don't move the code to a new language until the vast majority of your current toolchains do support that language. If you are going to ask downstreams users of your project "sorry, but you are just going to have to change toolchains/dev envs if you wanna use the latest", it's not gonna fly.
2. My personal experience is that a good static analyzer can be as effective as identifying memory leak and related issues in C source as switching to a language that is designed around preventing them. And I guess I am partially to blame on not having followed up on the many issues that I saw Coverity pick up against the libcdio base (which actually led me to silence Coverity on the libcdio part in my project, because there were just too many to address), which I told myself I would do one day when I have the time... Agreed, it will never be as good as Rust, but if it can get you 99% of the way there, this is nothing to be dismissed and I think that time would be better spent addressing these static warnings, and keeping the toolchains as they are. Sadly, Coverity is down right now, so I cannot show what it picks.
3. It's hard to see how libcdio, which aims at providing support for a dying form of media (anything that has to do with CD/DVD drive access or CDDA or videoCD) is likely to cross the path of "Rust-heads" (NB: I am not trying to use the term derogatively here). Outside of UDF and ISO-9660, I fail to see who would want any other part of libcdio ported to Rust. So, IMO, it would be much better to spin-off the file system parts, and the file system parts only, into a completely independent project.
4. Yes, stagnation is death. But I don't believe libcdio is stagnating because it uses C. Heck, I too am responsible for its stagnation, because there are things that I should have been looking at, but never got the time/priority for, such as addressing the Coverity issues. I am doubtful that we will see a fresh stream of active young blood if we happen to switch to Rust. Developers, no matter if they code in C or Rust, will do what they've always done with library dependencies: propose patches for the parts that matter to them, and let the project "stagnate" on the parts they don't. IMO, the reason libcdio stagnates is because of what I mentioned above: a lot of it is very niche and (outside of the file systems) pretty much obsolete. Rewriting these parts in Rust would provide as much benefits as rewriting, say, old Amiga C software in Rust. Sure, it's probably a great exercise, and you will rightfully be able to pat yourself on the back for doing so. But you gotta ask yourself, how many users are actually going to benefit from this rewrite.

[rocky]

I've had this in the back of my mind for a while...

With respect to 1.

libcdio's support toolchain is not that onerous. Compare, for example, with https://github.com/passagemath/passagemath/actions/runs/26155120255 and https://github.com/passagemath/passagemath/actions .

"sorry, but you are just going to have to change toolchains/dev envs if you wanna use the latest"

As I said, for a while, there will be parallel development. People vote by doing. If folks are interested in moving forward with libcdio in C, there's never been anything that stops them. And if, on the other hand, folks are interested in moving forward in Rust or some other parallel effort, there should not be something to stop that either. Where it makes sense, I'll do ports between the two.

But this really isn't the main point or what was in the back of my mind.

It was more about points 3 and 4, and the obvious observation that CD, DVD medium reading, Audio CD formats, CD-Text, file format specifications like Rock Ridge extensions to the ISO-9600 filesystem are not really a hot topic. So, of course, you'd expect a program like this to die off.

Therefore, I want to come back to a little story about how all of this came about. As I've written in the docs, my involvement was in order to beef up VCD's as a viable alternative to what, at the time, was DCMA-protection of DVDs circa 2000.

I came across a Video CD (VCD) authoring tool called vcdimager. To do VCD authoring, reading is also desirable. So my initial take was just to isolate the reading routines so that they could be used as a plugin in popular media players like (back then) VLC, xine, and mplayer.

In doing just this, others got interested in Audio CDs, extracting metadata information from the (CD-Text, which is not used in VCDs), exact audio ripping, using in booting computers and OS's, issuing hardware commands to MMC, devices, and possibly other things.

The point is, the future may not be about what this library is currently, but more importantly, where contributors want to take it.

In that respect, having a more modern platform to use and build off of is more likely to be amenable to the future direction of this software.

If you are in the camp that wants libcdio to remain in C, doing what it currently does with possibly minor tweaks, yes, you can still use, contribute, and extend the C code to the extent you want and are able to.

[rocky]

This summer, the project has been blessed to have someone working on it as part of Google's Summer of Code.

In the course of this work, and using Rust, a type-safe programming language, several weaknesses in the C code have not only been uncovered but also fixed.

I've long had a gut feeling, or had known outright, that there were various shortcomings in the code. So I am grateful that some of these are now getting addressed.

Although we are only halfway through the project, here are thoughts on how things might likely play out.

At the end of the program, there will be a new release of libcdio from 2.3.0 to possibly 2.4.0. This will contain all of the libcdio bugs found and fixed during Summer of Code as well as some others reported recently.

There will also be a release of two new packages, implemented in Rust:

• libcdio-rs: A safe Rust abstraction over libcdio C
• libcdio-cli: The CLI programs provided by libcdio (under src/)

These can be found in the cdio-rust repository.

Note: As we are having a rewrite, we've taken this opportunity to improve the programs' output. For example, see #9. This may affect any programs or scripts that use libcdio's CLI programs.

After a beta and acceptance phase, the CLI programs in libcdio C would be removed when libcdio-cli is complete with all the programs. This would be a libcdio 3.0.0 release.

This does not affect the library users of libcdio.
We are not introducing Rust in libcdio C.

Thoughts or comments?