> I usually find myself wishing I could have some macro where I just write in C and have it exposed as an unsafe back in Rust.

In D you can just import a .c file mycfile.c with:

    import mycfile; // C file filled with C functions

and they'll be treated as @system code by the D semantics. They're even inlinable.

Here's one that does that: https://lib.rs/crates/inline-c

I'm not sure it's what you're looking for, but it seems like a good starting point.

As for the general thrust of your comment and the article, I agree. It'll be interesting to see what changes come to make things nicer.

This one runs the C code as a program, so the code doesn't really communicate. I made a proof of concept some time ago of a macro that really translates C to Rust at compile time: https://github.com/zdimension/embed-c

> I usually find myself wishing I could have some macro where I just write in C and have it exposed as an unsafe back in Rust.

There’s a macro for doing this with Assembly, I can imagine one could be made for C. But why wouldn’t you just write unsafe rust at that point?

Perhaps because you want to import something you don’t want to rewrite? There’s a lot of tested C code out there.

That's a good point.

Colocation, and avoiding the ceremony of standing up all the extern types (and integrating a separate C compiler, etc)

You are not alone. The other day I was checking out a new programming language and the author rewrote the unsafe rust part to zig: https://github.com/roc-lang/roc/blob/main/FAQ.md#why-does-ro...

This was quite literally the motive for this article.

who reads articles? (joking ;) my bad)

One big difference between unsafe Rust and C is that C compilers have flags to turn off the UB, so you have a lot less mental load when writing it. You go from e.g. "if this index calculation overflows, we may read from outside the array, because the bounds check was deleted" to "if this index calculation overflows, we may read from the wrong index, but never outside of the array bounds". UB is Damocles's sword and the speed gains are usually not worth it. With UB your program can enter a buggy state that you cannot detect, because "it cannot happen". Without UB, your program can still enter a buggy state, but you can detect it and potentially recover or crash immediately before even more things go wrong.

Very true and worth evangelizing to others. I have unknowingly violated -fstrict-aliasing in some part of my code only to discover later that it is benign at -O0 and metastasized at -O3.

This freaks me out the most in networking code, where there is all kinds of casting of structs (esp. if you blindly copy-paste examples from StackOverflow) and performance usually matters. Rust has inspired me to take more time to profile C code to see whether strict aliasing (strict overflow, etc.) actually make a significant enough improvement to merit the UB-risk, review time, and acid in the stomach.

Which compiler flags do I use to turn off UB?

Are all the UBs defined/documented/catalogued somewhere?

Some flags to turn off some UB, and not all of them have those flags.

Shameless self-plug: https://github.com/zdimension/embed-c

This transpiles C to Rust at compile time, though it requires a nightly compiler and hasn't been updated in some time. But it's exactly what you're looking for. C code in, unsafe Rust code out.