News for hackers. Stuff that matters.
Re:Modern C (2019) by torstenvl on Friday June 02, 2023 @01:43PM (#36168344)
I'm okay with undefined behavior, but the language should revert back to the original (an exhaustive list of permissible behavior by the host when the C abstract machine's behavior is undefined) rather than the current mere list of examples of possible behavior by the host.
Re:Modern C (2019) by stouset on Friday June 02, 2023 @02:11PM (#36168754)
"I'm okay with undefined behavior, as long as its behavior is well-defined."

You keep using that word. I don't think it means what you think it means. :)

Re:Modern C (2019) by Dylan16807 on Friday June 02, 2023 @02:39PM (#36169046)
A behavior like "corrupts whatever is in memory at that location" when your code screws up a pointer is not exactly "well-defined", but it does disallow "pretends it could have corrupted RAM and does whatever it feels like instead".
Re:Modern C (2019) by stouset on Friday June 02, 2023 @07:35PM (#36172181)
Your platform almost certainly does do something sane and reasonable for UB-exhibiting code.

Where your problem lies is what happens when you optimize that code. And guaranteeing optimizations do something superficially sane on unsound code while still performing reasonable and obvious optimizations for well-formed code is insanely hard.

The fundamental problem is that the design of C guarantees that lots and lots and lots of syntactically valid and intuitively written code is semantically total nonsense. Part of this is that C is low-level and part is just that it was designed 50 years ago before anyone had the faintest idea what kinds of terrible mistakes were being made.

If there were simple fixes here it wouldn’t still be a problem.

Re:Modern C (2019) by Dylan16807 on Friday June 02, 2023 @09:02PM (#36172686)
> Where your problem lies is what happens when you optimize that code. And guaranteeing optimizations do something superficially sane on unsound code while still performing reasonable and obvious optimizations for well-formed code is insanely hard.

It really depends on the type of optimization.

A lot of the scariest results come when the compiler treats code as dead, and in very many cases you could go ahead and emit the code anyway and performance would be fine.

> If there were simple fixes here it wouldn’t still be a problem.

Nobody is trying to reduce the scope of UB, though. Even things that are very easy to define or implementation-define like syntax errors or left shifting with certain parameters are still sitting on the list.

Re:Modern C (2019) by torstenvl on Friday June 02, 2023 @04:46PM (#36170534)
Plenty of things are undefined, yet bounded. And being bounded does not mean that something is well-defined.

The number of elements of the set of real numbers between 1 and 2 is undefined, but we can say with absolute certainty that 3.5 isn't one of them.

Re:Modern C (2019) by giomasce on Saturday June 03, 2023 @12:38AM (#36173763)
So, which behaviours should be allowed for this code?

    void (*f)() = (void (*)())rand();
    f();
Re:Modern C (2019) by torstenvl on Saturday June 03, 2023 @01:22PM (#36178557)
The three enumerated options in the ANSI C standard and no others, especially not invisibly modifying non-dead code during translation.

The compiler could behave in a documented manner with or without a warning; it could error out and stop translation; or it could do what you fracking told it to, consequences be damned.

Re:Modern C (2019) by giomasce on Sunday June 04, 2023 @04:00AM (#36183872)
So it should never do function inlining, or replace multiplication by two with a bit shift? Because both of them quite fit "invisibly modifying non-dead code during translation".

> or it could do what you fracking told it to, consequences be damned

Yes, that's precisely what happens. The point is agreeing on what you "told it". The agreement stipulated in the standard is that in some cases (when you hit UB) you're effectively not agreeing on anything, i.e., the compiler can do what it want.

If that's not what you like, please let me know what should be mandated in the case of the fragment I wrote above, and how a compiler could offer that guarantee in an efficient and effective manner.

Re:Modern C (2019) by torstenvl on Tuesday June 06, 2023 @05:19PM (#36219254)
As to your first point: fair. It shouldn't modify it in a semantically material way.

> that's precisely what happens

No, it really isn't. Numerous compilers do static analysis to identify code that could be UB and then mangle it to mean something entirely different or eliminate it entirely. And if the compiler really did already do this, you wouldn't need to resort to...

> the compiler can do what it want[s]

Under current standards, yes, but that's a circular and nonsensical argument. You can't base your argument on what the standard permits when the very content of what the standard should be is the topic of discussion.

> please let me know what should be mandated

I already responded. The ANSI C standard is clear, and the modification to that language in subsequent ISO standards is, in my opinion, ill-advised.