Repercussions for potential future C flags?

Posted Apr 26, 2023 1:01 UTC (Wed) by swilmet (subscriber, #98424)
Parent article: An update on the GCC frontend for Rust

I wonder, and don't know if it has already been discussed, but would this work be useful (eventually) to the C frontend as well?

To basically treat some parts of the C language as if it was Rust code, but with the C syntax.

The C syntax lacks a lot of Rust concepts of course, but nothing prevents from adding annotations to the code, in special comments that would be understood by the added CFLAGS. Also, the C language is not completely dead, the standard evolves.

Because it would be easier to refactor C code to such a subset-of-C-and-Rust-like language, rather than working in parallel with two main programming languages (C and Rust) in the same project.

Repercussions for potential future C flags?

Posted Apr 26, 2023 4:50 UTC (Wed) by tchernobog (guest, #73595) [Link] (17 responses)

It is a bit hard to do, because of the amount of assumptions rust code is allowed to take due to the absence (in not-unsafe code) of undefined behavior.

Unfortunately, C's design makes it very hard to take certain assumptions and even produce good warnings (producing errors would clearly break compiling against the standard).

C++ already does introduce a lot more restrictions, and compiling C code with the C++ compiler is commonly done for that reason.

If you want to build on top of C, probably an approach with a transpiler would be what you want, like Kotlin did with Java.

There is https://ziglang.org/ which is a good attempt in the right direction.

Repercussions for potential future C flags?

Posted Apr 26, 2023 7:46 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (2 responses)

It's probably more helpful (especially if you ever write unsafe Rust) to think of it as: all Rust code is forbidden from doing a LOT of things that would seem pretty innocuous in C, however Safe Rust is checked so there's no mental overhead, if you tried to do any of these forbidden things the compiler stops you. Unsafe Rust has the exact same rules, but nobody else is ensuring you follow them. If you break any of the rules it's your fault when the program misbehaves, as a result writing Unsafe Rust is definitely harder to get right than C - but the idea is that you should need this rarely if at all.

Aliasing is the most obvious example of something forbidden in Rust but normal in C. Merely creating a mutable alias (e.g. int foo = 1; int *bar = &foo; in C) is forbidden in Rust. Even if you promise never to actually mutate it - even if the compiler can easily see that you don't - the construction of this Wrong Thing puts you on the far side of the rules.

Repercussions for potential future C flags?

Posted Apr 26, 2023 8:39 UTC (Wed) by matthias (subscriber, #94967) [Link] (1 responses)

> Merely creating a mutable alias (e.g. int foo = 1; int *bar = &foo; in C) is forbidden in Rust.

Fortunately, the borrow checker will prevent creating aliases to mutable references, even when you are using unsafe rust. In unsafe rust you will usually deal with raw pointers. And it is perfectly valid to have aliasing raw pointers as long as you take care of data races. Thus you basically have to uphold the same invariants as in unsafe C. [*]

Of course, at the boundary to safe code you have to ensure that you only create one mutable reference from your raw pointer, but that should be easy to comply with. And you are not allowed to mutate the state through your raw pointer while there exist any references (mutable or shared). So, it should not be that hard after all to create correct unsafe rust code. And -- as you said -- you will rarely need it at all and you can therefore be extra cautious at the places where you really need this.

[*] There is no such thing as safe C ;)

Repercussions for potential future C flags?

Posted May 3, 2023 11:13 UTC (Wed) by ssokolow (guest, #94568) [Link]

Not quite. There are ways to synthesize aliasing pointers from raw pointers in unsafe Rust which are UB that the optimizer may recognize but the type-checker can't catch.

As Aria Beingessner has written about in Rust's Unsafe Pointer Types Need An Overhaul, there definitely is improvement to be done.

I've seen at least one talk demonstrating examples of how stuff like that in unsafe Rust can be a footgun because there's an intuitively obvious way to do something, but it results in something like "casting through a reference" and, thus, invokes undefined behaviour. (With the proper solution being to use some function under std::ptr to manipulate the raw pointer directly.)

Repercussions for potential future C flags?

Posted Apr 26, 2023 10:54 UTC (Wed) by swilmet (subscriber, #98424) [Link] (13 responses)

Or, what about a transpiler C --> Rust.

Not for the full C specification, just a very small subset of C at the beginning. Like starting with a blank page, but keeping the familiar syntax of C.

Repercussions for potential future C flags?

Posted Apr 26, 2023 11:46 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

Something along the lines of C2Rust? Transpiles C to Unsafe Rust that's supposed to be semantically the same, and then you are able to gradually refactor the Rust from a very literal interpretation of your C into good-quality Rust (possibly while maintaining the C interface - depends on what you're doing).

Repercussions for potential future C flags?

Posted Apr 26, 2023 13:53 UTC (Wed) by swilmet (subscriber, #98424) [Link] (3 responses)

Interesting, but I had more in mind a transpiler for: subset of C --> safe Rust code.

And gradually "oxidizing" a C codebase to such safe subset of C.

Repercussions for potential future C flags?

Posted Apr 26, 2023 14:24 UTC (Wed) by ojeda (subscriber, #143370) [Link] (2 responses)

A few of us within WG14 support introducing a "safe" subset (or similar approaches or features) within ISO C.

However, even if we did get enough support for something like that, please note that if it is really just a subset of current C, then there is little you would be able to do inside it.

For instance, most C functions that take a pointer would be unsafe (in Rust terms). Similarly, a lot of expressions would not be allowed unless you remove the UB from them somehow, which in turn may make them surprising, even if only in terms of expected codegen.

Repercussions for potential future C flags?

Posted Apr 26, 2023 16:52 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

What would be the intended application of such a "safe subset" ?

Where we can afford to give up general applicability I would prefer the trade WUFFS takes, where we get to be arguably even safer than Rust and go real, real fast (because we proved so much about the code at compile time, our optimisations can be extremely aggressive with no risk of nasty surprises) in exchange for just writing off general purpose software development entirely as a goal.

I think we do too much general purpose software development and so we lose sight of the fact that many of our problems are only daunting (or outright insurmountable) in the context of general purpose software, if we're OK with saying no, I only want to (for example) turn blobs of data into RGB pixels, or (another example) turn PCM audio into different PCM audio, many of the trickiest problems we have are quite tractable. Not everybody needs to write the Linux kernel, the Linux kernel already exists, many of us could write something less... comprehensive ? amorphous ?

Repercussions for potential future C flags?

Posted May 3, 2023 10:47 UTC (Wed) by ssokolow (guest, #94568) [Link]

Agreed.

As someone who came to Rust from languages like Python for the maintainability (Haskell's type system may be stronger, but its ecosystem ethos is less suitable and the GC makes it much less suited to writing modules I can also reuse in things like PyQt GUI apps), rather than the performance, my ideal world would would involve a version of WUFFS that's written in and compiles to Rust.

(So that I don't sacrifice the comfortable workflow and ease-of-cross-compilation from working on a Rust project where the only C dependency is that final link stage between the standard library and the platform libc to access stuff like the ABI stability boundary for the Windows or macOS or BSD kernels.)

Repercussions for potential future C flags?

Posted Apr 26, 2023 11:53 UTC (Wed) by smoogen (subscriber, #97) [Link] (5 responses)

Again the issue is with the large amounts of undefined behaviour in the C standard. That undefined behaviour is usually there for one of the following reasons:
1. There are differences in how architectures actually do something so if you define a specific behaviour your compiler will be useless.
2. Some architetures actually do different things depending on outside factors, so again defining the behaviour will result in failure.
3. There are strong differences of opinion on what the proper thing to do is. While these usually get parlayed by various people as 'vested interests' from some company or manufacturer, they are usually the same as vi vs emacs. People's brains can come up with specific ways which solve a problem for them better and they stick to it.

Repercussions for potential future C flags?

Posted Apr 26, 2023 12:06 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

And surely much of that could be fixed?

(1) should be a simple case of "hardware defined". Maybe a switch to force counter-intuitive behaviour if required. If you rely on ones-complement and enable that flag on a twos-complement piece of hardware, you deserve what you get ...
(2) this might be a case of (1) or it might not. I can imagine - SCADA in particular - where you don't know what the hardware is going to do. Maybe you shouldn't be using C :-)
(3) make this a case of "if you don't ask you don't get". Compilers must implement at least one defined behaviour, and have a compiler flag to enforce it. Asking for an unimplemented behaviour is a compile time error, not asking is you get what you asked for :-)

Option (3) in particular is likely to result in a marked increase in the quality of C programs, I would have thought ... and a marked DEcrease in the number of programs that stop working when the compiler is upgraded :-)

Cheers,
Wol

Repercussions for potential future C flags?

Posted Apr 27, 2023 11:32 UTC (Thu) by calumapplepie (guest, #143655) [Link] (2 responses)

Making behavior dependent upon compiler flags is a big mistake. You should be able to tell what code will do based on the code: if some distributor's default mixes in flags you weren't expecting, that then change what your code does, life won't be great.

Repercussions for potential future C flags?

Posted Apr 27, 2023 12:40 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> You should be able to tell what code will do based on the code

I couldn't agree more. But if you actually read the context, how on earth are you supposed to tell what the code will do if it's undefined? Is it going to format your hard drive? Better a compiler switch, than random changes depending on the phase of the moon ...

Cheers,
Wol

Repercussions for potential future C flags?

Posted Apr 27, 2023 19:28 UTC (Thu) by khim (subscriber, #9252) [Link]

> But if you actually read the context, how on earth are you supposed to tell what the code will do if it's undefined?

Easy: you just look on the assembler code.

That's, ultimately, the reason C is dead: it's not technical, it's social.

Lots of people are not looking on C program as, well, C program.

Instead they think about machine code generated and for them C code, C compiler and C itself is merely a tool which allows them to produce assembler code they want.

And if they couldn't find a “nice”, documented way to achieve what they want they would just write program full of UBs and tweak it till generated assembler wouldn't be satisfying.

And, of course, it actually makes it impossible to write compiler which wouldn't mishandle such programs.

That's basically why C couldn't be fixed by changing the specs. Unless you are doing what Rust is doing all changes to the specs wouldn't amount to much.

Repercussions for potential future C flags?

Posted May 3, 2023 11:03 UTC (Wed) by ssokolow (guest, #94568) [Link]

3. There are strong differences of opinion on what the proper thing to do is. While these usually get parlayed by various people as 'vested interests' from some company or manufacturer, they are usually the same as vi vs emacs. People's brains can come up with specific ways which solve a problem for them better and they stick to it.

That's a bit of an understatement, given what a soul-crushing struggle it was just to get #embed, rife with things like double standards and bad-faith acting... and #embed is a fairly isolated feature with minimal effect on existing behaviours and features.

Repercussions for potential future C flags?

Posted Apr 26, 2023 12:56 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

Consider a<<=b. if the compiler output the local asm equivalent of 'shl a,b',
if b >= sizeof(a)*8, the result will depends on the CPU.
So if you want to remove the 'hardware defined behaviour', you will have to make this operation
several time slower than needed on some CPU.
So your transpiler might generate code that is much slower than the original C code.

Repercussions for potential future C flags?

Posted Apr 26, 2023 13:44 UTC (Wed) by swilmet (subscriber, #98424) [Link]

> So your transpiler might generate code that is much slower than the original C code.

If what the transpiler takes as input is a proper subset of C, then a full C compiler can be used too, and the transpiler to Rust would serve as additional sanity checks (like other static analysis tools: Coverity Scan, etc).

Repercussions for potential future C flags?

Posted Apr 26, 2023 14:51 UTC (Wed) by cyperpunks (subscriber, #39406) [Link]

Rust is here and it works very, very well. It resolves a large number of issues in C/C++, start to port your code today :-)