4 ms·

I just started porting an application using corrode on a C library at work. This was more of a POC, to show the team. Based on that, I think this book is missin

I just started porting an application using corrode on a C library at work. This was more of a POC, to show the team. Based on that, I think this book is missing a section on incremental conversion. You don't want to convert entire applications at once, you want to do it a source file or module at a time. This means incorporating the Rust toolchain into the build of the C/C++ project Makefile, or etc., system. It is not difficult, and will increase confidence in the final product. This can even be used to test incremental conversions in production, rather than having any doubt about the entire conversion. This is an awesome start for a great manual on the area. I'm very inspired by the experience I had in doing this, and hope that we do more.

tom_mellior 10y ago
> I just started porting an application using corrode on a C library at work. Can you tell us a bit about your experience with Corrode? The Readme itself states that it's not expected to work on "real" code, and there are open issues like this: https://github.com/jameysharp/corrode/issues/52 https://github.com/jameysharp/corrode/issues/52 titled "Arrays are broken!" in which Corrode's developer wrote half a year ago: "The current hack gets arrays translated correctly in function arguments, but gets them wrong everywhere else." In your experience, does it work better than this makes it seem? (To be somewhat fair, the issue does have detailed discussion, and partial fixes seem to have been merged, but it's still open.)
- bluejekyll 10y ago
  I didn't run into the Arrays issue. This issue I filed, has a list of all the things I hit: https://github.com/jameysharp/corrode/issues/109 https://github.com/jameysharp/corrode/issues/109 Most of the issues I ran into were not exactly with the corrode tool, but with compiler options, i.e. passing the DARWIN_C_LEVEL flag for macOS (my main dev machine). Actually, the library I hacked on was only built for Linux, I spent a lot of my time converting the C to multi-platform, not because it was necessary, but because I didn't feel like running a VM. What I found is that corrode produces mostly compilable code. I had played around a bit with FFI from C to Rust before, so the task of integrating a Rust library into a C codebase was already familiar to me. I would love to see a guide for doing that in corrode though, like an example project, for others. If I have time I might do that. One really cool thing, is that the Rust compiler detected some undefined behavior in our C code, which I filed a bug for to our team (it was an uninitialized stack variable, passed as a pointer to a function; in practice it would never actually rely on the undefined behavior since all the fields of the struct were set in that function, but it's still poor form). There are some things which you will need to massage, but I found in general that it wasn't much. I had a problem with null function pointer creation that I need to go back and look at. I think my biggest issue, is that every conversion produces unsafe code in Rust. It's left up to the developer to figure out how to convert it to safe code. I think this is ok, but unsafe is still dark arts for me in Rust (meaning that I don't completely grok the best practices right now). I need to go back and reread the Rustonomicon: https://doc.rust-lang.org/nightly/nomicon/ https://doc.rust-lang.org/nightly/nomicon/ , as there may be more details there than the last time I checked it out. I would love it if corrode could try and produce more safe blocks of code, but I also understand why it's this way. Anyway, I think it's an awesome tool, works 95% of the time, and you can probably easily come up with some standard techniques for going back to fix up the commonly incorrect cases. I'll reiterate this: integrate the Rust code into your C build right at the beginning (I used Cargo + staticlib), I even made this optional in my setup, so that you can flip between the two implementations easily for testing. I set up a make recipe which converts the C src to Rust with corrode (to capture all the CFLAGS needed), and that will only run as long as the .rs file doesn't exist. I found this to be very powerful for verification. I'd highly recommend corrode at this point, but don't be misled to believe that you won't need to make changes to the produced code. Edit: I should mention that to get all this setup, with all the C library fixes in macOS included and the Makefile integration, it took me 6 hours to get setup, with about 10-15 minutes spent actually making the produced .rs file compile.
demarq 10y ago
>This means incorporating the Rust toolchain into the build of the C/C++ project Makefile, or etc., system. One warning I can give you based on recent HN posts: Embrace Rust fully. Many expect Rust to be a "safe C++" or something of the sort, and try to port not only the code but their way of thinking into rust... which leads to pain and frustration. You seem to have lots of experience so maybe you already know that, but I'm pointing it out just in case ;)
- bluejekyll 10y ago
  Well, I've been working with Rust now for going on 2 years. And I know C and have very outdated C++ experience. I'd say C best practices probably translate better to Rust than C++, but with solid systems knowledge, as long as you don't fight the language, and instead try and embrace it, I think it's fine. I think a lot of people want to bring old patterns to Rust, some translate, some don't, but fundamentally the memory system is basically the same.

tom_mellior 10y ago

> I just started porting an application using corrode on a C library at work. Can you tell us a bit about your experience with Corrode? The Readme itself states that it's not expected to work on "real" code, and there are open issues like this: https://github.com/jameysharp/corrode/issues/52 https://github.com/jameysharp/corrode/issues/52 titled "Arrays are broken!" in which Corrode's developer wrote half a year ago: "The current hack gets arrays translated correctly in function arguments, but gets them wrong everywhere else." In your experience, does it work better than this makes it seem? (To be somewhat fair, the issue does have detailed discussion, and partial fixes seem to have been merged, but it's still open.)

bluejekyll 10y ago
I didn't run into the Arrays issue. This issue I filed, has a list of all the things I hit: https://github.com/jameysharp/corrode/issues/109 https://github.com/jameysharp/corrode/issues/109 Most of the issues I ran into were not exactly with the corrode tool, but with compiler options, i.e. passing the DARWIN_C_LEVEL flag for macOS (my main dev machine). Actually, the library I hacked on was only built for Linux, I spent a lot of my time converting the C to multi-platform, not because it was necessary, but because I didn't feel like running a VM. What I found is that corrode produces mostly compilable code. I had played around a bit with FFI from C to Rust before, so the task of integrating a Rust library into a C codebase was already familiar to me. I would love to see a guide for doing that in corrode though, like an example project, for others. If I have time I might do that. One really cool thing, is that the Rust compiler detected some undefined behavior in our C code, which I filed a bug for to our team (it was an uninitialized stack variable, passed as a pointer to a function; in practice it would never actually rely on the undefined behavior since all the fields of the struct were set in that function, but it's still poor form). There are some things which you will need to massage, but I found in general that it wasn't much. I had a problem with null function pointer creation that I need to go back and look at. I think my biggest issue, is that every conversion produces unsafe code in Rust. It's left up to the developer to figure out how to convert it to safe code. I think this is ok, but unsafe is still dark arts for me in Rust (meaning that I don't completely grok the best practices right now). I need to go back and reread the Rustonomicon: https://doc.rust-lang.org/nightly/nomicon/ https://doc.rust-lang.org/nightly/nomicon/ , as there may be more details there than the last time I checked it out. I would love it if corrode could try and produce more safe blocks of code, but I also understand why it's this way. Anyway, I think it's an awesome tool, works 95% of the time, and you can probably easily come up with some standard techniques for going back to fix up the commonly incorrect cases. I'll reiterate this: integrate the Rust code into your C build right at the beginning (I used Cargo + staticlib), I even made this optional in my setup, so that you can flip between the two implementations easily for testing. I set up a make recipe which converts the C src to Rust with corrode (to capture all the CFLAGS needed), and that will only run as long as the .rs file doesn't exist. I found this to be very powerful for verification. I'd highly recommend corrode at this point, but don't be misled to believe that you won't need to make changes to the produced code. Edit: I should mention that to get all this setup, with all the C library fixes in macOS included and the Makefile integration, it took me 6 hours to get setup, with about 10-15 minutes spent actually making the produced .rs file compile.

demarq 10y ago

>This means incorporating the Rust toolchain into the build of the C/C++ project Makefile, or etc., system. One warning I can give you based on recent HN posts: Embrace Rust fully. Many expect Rust to be a "safe C++" or something of the sort, and try to port not only the code but their way of thinking into rust... which leads to pain and frustration. You seem to have lots of experience so maybe you already know that, but I'm pointing it out just in case ;)

bluejekyll 10y ago
Well, I've been working with Rust now for going on 2 years. And I know C and have very outdated C++ experience. I'd say C best practices probably translate better to Rust than C++, but with solid systems knowledge, as long as you don't fight the language, and instead try and embrace it, I think it's fine. I think a lot of people want to bring old patterns to Rust, some translate, some don't, but fundamentally the memory system is basically the same.