101–110 of 127 posts
On the one hand, you could use CSmith with a C compiler as a convenient oracle, but on the other you would only be covering a very limited subset of e.g. the type system.
I do get that Haskell is useful to be taken as a tool for these kind of code transformations (at least I have seen quite a few of those) but I am always a bit surprised that people would start such a project in a language that has -per se- nothing to do with either the source or the target language. I know, I know, it doesn't always have to be this way, but I am very much of the opinion that everytime good tools in a…
Haskell is very good at writing correct parsers easily—that's one thing. This is part of the reason it was chosen as an early perl6 test bed via pugs. Rust is getting there (I'm a big fan of the lalrpop library) but the ecosystem is no where near as mature as Haskell's for feature-complete libraries. The pace of development of the rust ecosystem is mind-boggling, though—I never guessed that rust would have taken off…
Earlier quoted context omitted.
Not to look a gift horse in the mouth, but it seems like Corrode misses some other chances to use idiomatic Rust: 1. Rust fn:main doesn't need to return something. 2. The arguments to main aren't mutated, so Rust doesn't need to declare them as mutable. 3. Ditto for the argument to printf. Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite d…
I think that keeping an exact one-to-one mapping makes this tool a lot more useful. There's no telling what code depends on C idioms that would be broken by using a Rust idiom instead. Generating 100% equivalent code means that programmers can make intelligent decisions about when to switch over to Rust idioms as they continue developing the program.
It's too bad this is written in Haskell. I don't have anything against Haskell, it is just not as popular a language as others.[1] Any ANTLR target language would have been a solid choice.[2] This way more of the community could contribute. This is an invaluable tool if we're truly going to see a shift from C (or C++) to Rust. [1] http://pypl.github.io/PYPL.html [2] http://www.antlr.org/download.html
Has anyone tried it on some real-world codebases? How about kernel code? It would be very exciting to improve real-world crash safety and security by e.g. converting popular drivers quickly and automatically, followed by a manual pass applying safer Rust semantics.
as many "transpilers" / compilers, whatever you might name them, it lacks example input output. I want to see how my new rust code base looks light, does it compile with some heuritics, or just 1:1 C to rust primitives?
I do get that Haskell is useful to be taken as a tool for these kind of code transformations (at least I have seen quite a few of those) but I am always a bit surprised that people would start such a project in a language that has -per se- nothing to do with either the source or the target language. I know, I know, it doesn't always have to be this way, but I am very much of the opinion that everytime good tools in a…
Has anyone tried it on some real-world codebases? How about kernel code? It would be very exciting to improve real-world crash safety and security by e.g. converting popular drivers quickly and automatically, followed by a manual pass applying safer Rust semantics.