This has always bothered me. If you are writing in a memory-safe Language like Rust, why would you ever use a C library that is not safe? I have seen this when somebody wants to connect to a piece of hardware using an odd memory footprint using the library provided by the manufacturer. If the hardware requires you to use unsafe practices, why are you using that hardware? If the answer is 'Legacy' and/or 'Costs', you had better be prepared for the technical and security debt you are incurring.
Of course you'd use a Rust library if you can, but in the immediate term it's not always possible.
There are mostly two scenarios. One is that it's a third party library that you are not qualified to rewrite yourself, and it's just not yet be done in Rust. That's generally a temporary issue that you can correct later when that Rust version shows up.
The other is that it's your own code and you are doing an incremental transition of your code base. Again, that's temporary if you choose it to be, it just lets you get going quicker.
Well, and a third is calling into the operating system, which has to be done at some level, unless you are going to rewrite Linux and Windows in Rust.
Things to keep in mind that you don't just call these C libraries all over the place. You wrap them into safe Rust APIs so the actual footprint for problem is much, much smaller.
The other is that, because these APIs are behind safe Rust interfaces, they will never receive invalid memory, and it's pretty straightforward generally to vet those calls and confirm they are being called correctly. So the primary concern is that the library will do something bad given valid inputs. For the OS or widely used libraries, that's a fairly low concern in the greater scheme of things.
Ultimately, when compared to the OS or a widely used library, my code is orders of magnitude more likely to have issues. If I prevent my code from passing bad data to the C calls, then that's a vastly better situation than C++ using those C libraries.
It gets more complex if there are trickly ownership issues involved. Most calls are just leaf node calls. You call out from Rust to them, some stuff goes in, some stuff comes out, and that's it. No ownership extends beyond that call. In some cases that's not true, like wrapping Windows overlapped I/O. In those cases much more care is needed.
Bonejob@reddit
This has always bothered me. If you are writing in a memory-safe Language like Rust, why would you ever use a C library that is not safe? I have seen this when somebody wants to connect to a piece of hardware using an odd memory footprint using the library provided by the manufacturer. If the hardware requires you to use unsafe practices, why are you using that hardware? If the answer is 'Legacy' and/or 'Costs', you had better be prepared for the technical and security debt you are incurring.
Full-Spectral@reddit
Of course you'd use a Rust library if you can, but in the immediate term it's not always possible.
There are mostly two scenarios. One is that it's a third party library that you are not qualified to rewrite yourself, and it's just not yet be done in Rust. That's generally a temporary issue that you can correct later when that Rust version shows up.
The other is that it's your own code and you are doing an incremental transition of your code base. Again, that's temporary if you choose it to be, it just lets you get going quicker.
Well, and a third is calling into the operating system, which has to be done at some level, unless you are going to rewrite Linux and Windows in Rust.
Things to keep in mind that you don't just call these C libraries all over the place. You wrap them into safe Rust APIs so the actual footprint for problem is much, much smaller.
The other is that, because these APIs are behind safe Rust interfaces, they will never receive invalid memory, and it's pretty straightforward generally to vet those calls and confirm they are being called correctly. So the primary concern is that the library will do something bad given valid inputs. For the OS or widely used libraries, that's a fairly low concern in the greater scheme of things.
Ultimately, when compared to the OS or a widely used library, my code is orders of magnitude more likely to have issues. If I prevent my code from passing bad data to the C calls, then that's a vastly better situation than C++ using those C libraries.
It gets more complex if there are trickly ownership issues involved. Most calls are just leaf node calls. You call out from Rust to them, some stuff goes in, some stuff comes out, and that's it. No ownership extends beyond that call. In some cases that's not true, like wrapping Windows overlapped I/O. In those cases much more care is needed.
Qweesdy@reddit
If a library written in Rust doesn't exist; would you rather:
a) Write the library yourself, and spend 5+ years dealing with a continual stream of bugs in new untested code; or
b) Use an existing library (in a different language) that's actually correct because it's been tested continuously by everyone for 30+ years?