[simonask]

This approach is harder than you might imagine. LLVM can do a lot of things that don't map to C language constructs. You cannot generally roundtrip arbitrary LLVM IR through some C representation. You can emulate most things, but you won't necessarily get the same LLVM IR in the other end.

[afdbcreid]

FWIW, Rust can also do a lot of things that do not easily map to C (at least standard C) constructs. For example:

- You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first.

- Signed integer overflow is UB in C, defined to wrap/panic in Rust.

- Type-based alias analysis is a big one, does not exist in Rust.

[tialaramex]

> You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first.

Indeed specifically Rust defines that pointer comparisons are done by address, whereas C doesn't specify what the rules are exactly. This gets sticky if the pointer was invalidated (e.g. you free'd the memory it was pointing at). Rust says - as you might expect - that you can still compare this invalid pointer to another pointer (which may or may not still be valid and indeed might be a valid pointer to the same address!) because we're only comparing the address - but C++ says you mustn't do that and I believe C has the same rule.

> Signed integer overflow is UB in C, defined to wrap/panic in Rust.

This doesn't feel like an interesting difference. C made a weird choice, which was maybe convenient for the usual Worse Is Better reasons 50+ years ago. LLVM doesn't care about that choice, LLVM can cheerfully simulate this behaviour in C if you want that.

> Type-based alias analysis is a big one, does not exist in Rust.

This also doesn't feel relevant but I guess I'm interested in why you think it would make "a big" difference?

Edited: I confirmed C11 has "pointer zap" which is the behaviour I described above, and I believe C23 also still has pointer zap although paulmck and co. are trying to get rid of it or do something on this topic in C2y.

[afdbcreid]

It makes a big difference if you want to translate Rust to C. TBAA means you cannot translate a Rust struct to a C struct if you want to stay in standards-compliant C.

[tialaramex]

Can you say more, maybe with an example of what goes wrong? I can't picture this in my head, when I picture translating some struct it feels like this works just fine, clearly I am missing something from what you're imagining.

[afdbcreid]

E.g. you cannot translate `#[repr(C)] struct Foo { v: i32, u: i32 }` to `typedef struct { int32_t v; int32_t u; } Foo;` because in Rust it's entirely valid to take a `&Foo` and view it as `&[i32; 2]`, while in C this is UB.

[1718627440]

Isn't the alignment for the struct and the array the same, because it is determined by the inner type?