Repercussions for potential future C flags?

Posted Apr 26, 2023 11:53 UTC (Wed) by smoogen (subscriber, #97)
In reply to: Repercussions for potential future C flags? by swilmet
Parent article: An update on the GCC frontend for Rust

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.