Catch-23: The New C Standard Sets the World on Fire • Hacker News Board

Re: Catch-23: The New C Standard Sets the World on Fire

#271

Post by saagarjha » Tue, Apr 04, 2023, 9:40 AM UTC

CJefferson wrote: post #116

coliveira wrote: post #73

Earlier quoted context omitted.

It is just the opposite. UB is a clarification to tell programmers what the language considers to be undesired behavior. If they didn't say anything, it would be always a mystery if a certain construct was allowed or not, effectively making it compiler dependent. Compilers would also have less avenue for creating optimizations. In the next iterations of the C standard we may see more constructs classified as UB.

Is the improved performance of C over say Java, or Rust (which both have much less undefined behaviour -- Java almost none) worth the pain and bugs which have been caused by UB? Honestly, I don't think so, and as computers get more powerful and the amount of the world which relies on their correct functioning grows, I feel the arguments for UB become increasingly difficult to justify.

Java can optimize programs to make well-defined but very rarely occurring cases be on the slow path. C can't really do this.

Re: Catch-23: The New C Standard Sets the World on Fire

#272

Post by mjevans » Wed, Apr 05, 2023, 8:20 AM UTC

skitter wrote: post #228

DangitBobby wrote: post #112

Earlier quoted context omitted.

Another option would be to define behaviors for integer overflow and out of bounds memory access. Presumably they happen fairly often and it might be a good idea to nail down what should happen in those cases.

That would be great if it was possible, but how do you specify & implement sensible behavior for this: void foo(int *a, int b) { a[b] = 1} At runtime there is no information about whether that write is in bounds and no way to prevent this from corrupting arbitrary data unless you compile for something like CHERI.

In checked languages this would probably be an 'unsafe' function, since it lacks those features.

If this were accessible at build time it could be checked for anything that references the function and bounds checked accordingly.

The promotion of a pointer to an array is really the source of the logical error. A language could place range checks on created arrays, and pointers / references to allocated arrays could be handled differently than anonymous slabs of memory. However an array without bounds (even stored elsewhere from just before the array's starting address) is as unsafe as 'null terminated strings' for length bounds. That's an idea that made much more sense when systems were much smaller and slower and the exposure to untrusted code and data were also far lower.

void foo(void *a, int b) { (int[])(a) = 1 } // Not quite C pseudocode, also see poke()

Re: Catch-23: The New C Standard Sets the World on Fire

#273

Post by rrobukef » Wed, Apr 05, 2023, 10:29 AM UTC

zefix wrote: post #263

rrobukef wrote: post #262

Earlier quoted context omitted.

I find this especially surprising because line 2 may be exactly the reason why line 5 is unreachable. E.g. if puts("A") contractually throws an exception you cannot just remove it. What am I missing in this example?

C does not have exceptions...

But it has long_jmp, right?

Re: Catch-23: The New C Standard Sets the World on Fire

#274

Post by AlotOfReading » Wed, Apr 05, 2023, 10:51 PM UTC

LegionMammal978 wrote: post #258

AlotOfReading wrote: post #257

Earlier quoted context omitted.

I think your confusion here is coming from the fact that "unspecified behavior" is a specific thing in the standard's terminology (looking specifically at n3088 right now), distinct from the concept of "undefined behavior". So when it says "constructed according to the semantic rules", that inherently excludes UB, which definitionally has no semantics prescribed for it (unlike unspecified behavior). For brevity's sak…

My claim is, "If a program violates the semantic rules at runtime given input A, but does not violate the semantic rules at runtime given input B, then the execution of the program given input B will be defined by clause 5." This is because the wording of 4/3 implies that "being constructed according to the semantic rules" is a function of both the program and the data it is given, such that the behavior can be defin…

I realized on thinking a bit more that two of the cases I mentioned are actually identical, so you're correct. Good to know going forward!

Re: Catch-23: The New C Standard Sets the World on Fire

#275

Post by c4mpute » Wed, Apr 05, 2023, 11:08 PM UTC

chongli wrote: post #236

c4mpute wrote: post #180

Earlier quoted context omitted.

> all you have to do to avoid UB on signed integer overflow is check for overflow before doing the operation All you have to do is add a check for overflow _that the compiler will not throw away because "UB won't happen"_. The very thing you want to avoid makes avoiding it very hard, and lots of bugs have resulted from compilers "optimizing" away such overflow checks.

This is covered in the article and numerous replies in this thread. Use .

stdckdint.h is only available in C23. The problem has existed before that and lead to tons of exploits and bugs.