It was easy to get the Rust code compiled and working as a drop-in-replacement for the C Library. This has been a big help with refactoring the unsafe Rust code into safe Rust (manual work). OpenJpeg has a great testsuite that has allowed testing that each refactor step doesn't add new bugs (has happened at least 3 times).

The original run of c2rust generated 96,842 lines of Rust code (about 1 year ago), now it is down to 46,873 lines code. A lot of the extra 50k lines of code were from C macros that got expanded and from constant lookup tables (C code had 10-30 values per line, Rust 1 value 1 line).

For anyone looking to use c2rust to port C code to Rust, I recommend the following:

  1. Setup some automated testing if it doesn't exist already.
  2. Do refactoring in small amounts, run the tests and commit the changes before doing more refactoring.
  3. Use "search/replace" tools (`sed`) to help with rewriting common patterns.  Make sure to follow #2 when doing this.
  4. Don't re-organize the code until after most of the unsafe code has been rewritten.  This will allow easier side-by-side comparison with the original C code.
  5. c2rust expands macros and constants from `#define`.  Being able to do side-by-side comparison of the C code will help with adding constants back in and removing expanded code with Rust macros or just normal Rust functions.

Comments URL: https://news.ycombinator.com/item?id=31606342

Points: 1

# Comments: 0

c2rust also has a refactor command that helps with refactoring the generated Rust code.

[0] https://github.com/Neopallium/openjpeg/tree/c2rust

This blog post shows how to write simple idiomatic Rust code that will allow the compiler to auto-vectorize:

http://cliffle.com/p/dangerust/6/

It is a great example of how the Rust compiler can auto-vectorize code.

0. http://cliffle.com/p/dangerust/6/

From what I have read so far is seems that AMD CPUs have had the fewest vulnerabilities/slowdowns? But I can't be sure since I haven't seen a complete comparison (including these new vulnerabilities).

The comment in the article was "…email about that 'thing'". I would immediately think "what thing?", then everything else goes down the drain.

Found that accidentally because of autocomplete on my phone changed "-ef" to "get".

I didn't really need the JIT feature. But I did add support for it because Lua code can dynamically generate/load more Lua code.

I just found that the runtime overhead (memory and stack space) of LLVM was too high for my needs.

That answer is about typed languages. The issue is with dealing with dynamic types. There is a lot more code generated for the JIT to compile.

Thanks for the heads up.

The main issues I had with LLVM was the partly do to the memory usage. It can product very good machine code, but the time needed to JIT a block of code was sometimes longer then just running the it in the interpreter.

One of the features I like about Lua the most is the low resource overhead. LLVM was just too big for what I was looking for.

Usage LLVM to JIT/AOT compile Lua code was really just an experiment, something I wanted to try out.

I re-wrote [0] the llvm-lua project with a simple C code-gen backend for compiling Lua code to native code. Which is a bit more useful, since it is easier to cross-compile pure C code, then LLVM bitcode. A lot of the people that tried using llvm-lua wanted to cross-compile Lua code and embed it into an iOS application.

0. https://github.com/Neopallium/slua