I agree, that's a waste of time I would have preferred to avoid. The lack of a such basic structures is something I really dislike in C.
> Remind me again, why C is a good thing and not a liability these days?
Ubiquity, portability, performance, interface with other languages…
One annoying point is that the core API, used by the modules, can change at any time (the modules are updated along with the API).
If there are Rust bindings for the core API [1], every API change must be reflected in Rust (and in modules written in Rust). This is problematic.
Many languages that compile to native code allow you to export functions in a way that they can be called from other C code.
This means you'd write your actual code in whatever language you want (possibly one that does have a generic vector in its standard library - but I guess these days that's anything but C) and then you'd just export a usable-by-C interface so other languages still get to interface with your implementation.
That's the wrong question. The question should be:
"If I rewrite this in a different language, will it be a net-benefit? If so, just how long will it take to reap said benefit?"
The trade-offs add a lot of nuance to that question and make it a harder choice.
a media player doesn't (or shouldn't at least) modify any of my essential data, so the worst it can really do is crash every now and then. for a program like vlc, mild instability is not a bad trade-off if it means less dropped frames on old computers.
Writing it in C for a marginal performance gain just isn't worth it.
Ask the Android team about the stagefright exploit.
Media players provide a huge attack surface. They are constantly exposed to untrusted files which are also very enticing for users to open (as opposed to, say, some spreadsheet)
Yes. A media player normally doesn't modify your essential data, but when it's written in an unsafe language, it is very likely to do so one way or another.
there's your problem.
I mean, I'm sure your `vlc_vector` you've spent so much time optimizing and securing is as good as or even better than `other_project_vector` and `some_library_vector` or maybe even `some_other_vector`
All of which were implemented by various projects out of necessity because the language they chose doesn't have such an essential data structure in its standard library and because the culture around the language values NIH more than anything else.
Remind me again, why C is a good thing and not a liability these days?