5 ms·

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 co

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?

steveklabnik 10y ago
> Because the project is still in its early phases, it is not yet > possible to translate most real C programs or libraries. It is currently trying to port over semantics exactly, so the Rust code is far from idiomatic Rust. Doesn't mean it's not useful, just saying that it's trying to be 1:1.
- moosingin3space 10y ago
  I guess the next stage would involve translating common non-idiomatic patterns into idiomatic Rust. Looks like this could be a job for a community-managed database!
  - stcredzero 10y ago
    This is best handled on a per-project or per-organization basis. I would have such a project concentrate on the tooling for maintaining and developing such databases.
  - Manishearth 10y ago
    On the rust subreddit someone tongue-in-cheek suggested `cargo clippy | rustfix` to be used in conjunction with this tool for better rust code. But that actually could work! Clippy has a ton of lints that make your code more idiomatic, and rustfix basically takes diagnostic output and applies suggestions (still WIP). Clippy is geared towards making human-written unidiomatic code better, so it might not catch some silly things in this tool's output but or certainly could be extended to do that.
    - moosingin3space 10y ago
      I haven't used nightly much, what all does Clippy do?
      - Manishearth 10y ago
        It tells you about places where you can improve your code. Possible pitfalls, style issues, documentation issues, unidiomatic code, everything. Its a developer tool so you can use rustup to switch to nightly to run clippy (and use stable otherwise) and not impose nightly on the rest of the people who use the project. We have plans for making clippy a tool that you can fetch via rustup without requiring nightly.
      - shepmaster 10y ago
        Check out Clippy online! Go do http://play.integer32.com/ http://play.integer32.com/, paste in your code, click "Clippy".
      - masklinn 10y ago
        It's a linter.
DanWaterworth 10y ago
Here you go. It didn't like my stdio.h. Apparently enums and unions aren't supported, but: extern int printf(char *, ...); int main(int argc, char argv[]) { printf("Hello, world!\n"); return 0; } Was turned into: extern { fn printf(arg1 : *mut u8, ...) -> i32; } #[no_mangle] pub unsafe fn main(mut argc : i32, mut argv : *mut u8) -> i32 { printf(b"Hello, world!\n\0".as_ptr() as (*mut u8)); 0i32 } edit: Also worth noting, it removes all comments. I believe this to be a limitation of language-c [1] [1] https://hackage.haskell.org/package/language-c https://hackage.haskell.org/package/language-c
- ape4 10y ago
  Shouldn't a C `int` be converted to Rust's `isize`. I think that captures the spirit better.
  - DanWaterworth 10y ago
    I'm in no way connected to the project. Perhaps you should file an issue.
  - dbaupp 10y ago
    They're different types. isize is ssize_t (well, intptr_t), in that it is tied to the size of the address space, while C's int is not constrained. In fact, it is usually 32 bits, even on 64-bit architectures, where isize is 64 bits.
    - wahern 10y ago
      Wow. So I did some sleuthing and apparently in Rust the maximum size of an object must fit in isize, not usize. That means on 32-bit architectures you can't have arrays larger than 2GB, whereas on Linux and similar systems 32-bit processes have access to 3GBs and even the full 4GBs of address space. It actually matters for things like mmap'ing files. Technically, C's int is constrained. C defines a minimum range of values for all the datatypes. The minimum range for int is -32767 to +32767. long is -2147483647 to +2147483647. Though the discerning pendant will claim, ex post, to target something like POSIX (which increases the bound on int, defines char as 8 bits, etc) if you point out improper use of int. One irony of criticisms against C is that people argue it's too low level, but that's often because people treat it as too low-level. For example, novice C programmers think of C integer types in terms of bit representations and infer value ranges. Good C programmers think of C integer types in terms of representable values, understand that bit representation (specifically, hardware representation) is almost always irrelevant, and understand how to leverage the unspecified upper bounds on value ranges to improve the longevity and portability of their software. Languages which emphasize fixed-width integers are, in some sense, a retrogression. The real problem with C integer types is you won't see the folly in poor assumptions until it's too late. Languages like Ada addressed this with explicit ranges. But I guess that was too burdensome. Fixed-width integers is an appeasement of lazy programming. I admit to being lazy and using fixed-width integers in C more than I should, but at least I feel dirty about it. Many of the compromises Rust makes are clearly informed by the _particular_ experiences of the core team. For example, the fact that most Rust developers are of the belief that malloc failure is not recoverable (a big hold-up in adding catch_unwind) is a reflection of their experience with large desktop software. Desktop software has very complex, interdependent, and less fine-grained transaction-oriented state. Recovering from malloc failure is very hard and of little benefit. Most server software, by contrast, has more natural and consistent transactional characteristics. Logical tasks have less interdependent state, so it's both easier and more beneficial to be able to recover from malloc failure. I think some of the choices wrt integer types is similarly informed.
deleted 10y ago
[deleted]

steveklabnik 10y ago

> Because the project is still in its early phases, it is not yet > possible to translate most real C programs or libraries. It is currently trying to port over semantics exactly, so the Rust code is far from idiomatic Rust. Doesn't mean it's not useful, just saying that it's trying to be 1:1.

moosingin3space 10y ago
I guess the next stage would involve translating common non-idiomatic patterns into idiomatic Rust. Looks like this could be a job for a community-managed database!
- stcredzero 10y ago
  This is best handled on a per-project or per-organization basis. I would have such a project concentrate on the tooling for maintaining and developing such databases.
- Manishearth 10y ago
  On the rust subreddit someone tongue-in-cheek suggested `cargo clippy | rustfix` to be used in conjunction with this tool for better rust code. But that actually could work! Clippy has a ton of lints that make your code more idiomatic, and rustfix basically takes diagnostic output and applies suggestions (still WIP). Clippy is geared towards making human-written unidiomatic code better, so it might not catch some silly things in this tool's output but or certainly could be extended to do that.
  - moosingin3space 10y ago
    I haven't used nightly much, what all does Clippy do?
    - Manishearth 10y ago
      It tells you about places where you can improve your code. Possible pitfalls, style issues, documentation issues, unidiomatic code, everything. Its a developer tool so you can use rustup to switch to nightly to run clippy (and use stable otherwise) and not impose nightly on the rest of the people who use the project. We have plans for making clippy a tool that you can fetch via rustup without requiring nightly.
    - shepmaster 10y ago
      Check out Clippy online! Go do http://play.integer32.com/ http://play.integer32.com/, paste in your code, click "Clippy".
    - masklinn 10y ago
      It's a linter.

DanWaterworth 10y ago

Here you go. It didn't like my stdio.h. Apparently enums and unions aren't supported, but: extern int printf(char *, ...); int main(int argc, char argv[]) { printf("Hello, world!\n"); return 0; } Was turned into: extern { fn printf(arg1 : *mut u8, ...) -> i32; } #[no_mangle] pub unsafe fn main(mut argc : i32, mut argv : *mut u8) -> i32 { printf(b"Hello, world!\n\0".as_ptr() as (*mut u8)); 0i32 } edit: Also worth noting, it removes all comments. I believe this to be a limitation of language-c [1] [1] https://hackage.haskell.org/package/language-c https://hackage.haskell.org/package/language-c

ape4 10y ago
Shouldn't a C `int` be converted to Rust's `isize`. I think that captures the spirit better.
- DanWaterworth 10y ago
  I'm in no way connected to the project. Perhaps you should file an issue.
- dbaupp 10y ago
  They're different types. isize is ssize_t (well, intptr_t), in that it is tied to the size of the address space, while C's int is not constrained. In fact, it is usually 32 bits, even on 64-bit architectures, where isize is 64 bits.
  - wahern 10y ago
    Wow. So I did some sleuthing and apparently in Rust the maximum size of an object must fit in isize, not usize. That means on 32-bit architectures you can't have arrays larger than 2GB, whereas on Linux and similar systems 32-bit processes have access to 3GBs and even the full 4GBs of address space. It actually matters for things like mmap'ing files. Technically, C's int is constrained. C defines a minimum range of values for all the datatypes. The minimum range for int is -32767 to +32767. long is -2147483647 to +2147483647. Though the discerning pendant will claim, ex post, to target something like POSIX (which increases the bound on int, defines char as 8 bits, etc) if you point out improper use of int. One irony of criticisms against C is that people argue it's too low level, but that's often because people treat it as too low-level. For example, novice C programmers think of C integer types in terms of bit representations and infer value ranges. Good C programmers think of C integer types in terms of representable values, understand that bit representation (specifically, hardware representation) is almost always irrelevant, and understand how to leverage the unspecified upper bounds on value ranges to improve the longevity and portability of their software. Languages which emphasize fixed-width integers are, in some sense, a retrogression. The real problem with C integer types is you won't see the folly in poor assumptions until it's too late. Languages like Ada addressed this with explicit ranges. But I guess that was too burdensome. Fixed-width integers is an appeasement of lazy programming. I admit to being lazy and using fixed-width integers in C more than I should, but at least I feel dirty about it. Many of the compromises Rust makes are clearly informed by the _particular_ experiences of the core team. For example, the fact that most Rust developers are of the belief that malloc failure is not recoverable (a big hold-up in adding catch_unwind) is a reflection of their experience with large desktop software. Desktop software has very complex, interdependent, and less fine-grained transaction-oriented state. Recovering from malloc failure is very hard and of little benefit. Most server software, by contrast, has more natural and consistent transactional characteristics. Logical tasks have less interdependent state, so it's both easier and more beneficial to be able to recover from malloc failure. I think some of the choices wrt integer types is similarly informed.

deleted 10y ago

[deleted]