Repercussions for potential future C flags? [LWN.net]

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).