I believe this is barking up the wrong tree since IMHO C is just "high level assembly" for systems programming. As soon as you add runtime behavior to combat Undefined Behavior (UB) you're blowing up execution times. And static analysis can only go so far without blowing up compile times.

C is "the right tool for the right job" which is operating systems and its code which is called thousands of times per second. You cannot afford even one iota of runtime checks in that code. The developer must know what he's doing or he should get out of the kitchen.

We should discourage the usage of C in application programming and prod application developers towards memory safe languages like Rust or Go.

And I'm not even sure if Rust solves this case as far as UB is concerned.

▲

flohofwoe 8 minutes ago | parent | next [-]

> "high level assembly"

That's already a fundamentally wrong assumption :) With today's compilers, C is a high level language like all the others. The optimizations happening to C code are not fundamentally different than for any other compiled high level language.

> We should discourage the usage of C in application programming and prod application developers towards memory safe languages like Rust or Go.

No that's rubbish, just as it would be rubbish trying to 'discourage' people from writing programs in assembly code or any other programming language.

Ultimately, memory safety is the job of the sandbox your untrusted code is running in (e.g. the browser, operating system or VM).

The only difference between Rust and any "unsafe" language should be that one fails already at compilation time and the other at runtime (because the sandbox killed your rogue process).

E.g. if an operating system is exploitable because it allows untrusted programs to reach out of the sandbox, then that problem must be fixed in the operating system.

▲

SkiFire13 3 hours ago | parent | prev | next [-]

> C is just "high level assembly" for systems programming

It is not, and that's the issue. If it was just "high level assembly" there would be no UB, and no need to have UB. Instead you have UB (although arguably not all of it is really needed) because you need optimizations, which in turn you need because otherwise C would be too slow for that "operating system" job.

> code which is called thousands of times per second

Scripting languages can easily have loops running thousand of times per second and even more. You're off by some order of magnitudes here if you want to describe operations that happen in operating systems.

▲

gizmo686 3 hours ago | parent | prev | next [-]

A high level assembly would not have a UB problem, because the generated machine code would closely map to your source code, so even technically undefined behaviour would end up doing the expected thing for the given hardware.

The problem with C is that modern compilers do a lot of transformations between your source code and the final machine code, so the actual behavior could be very far afield from what you would expect.

> And I'm not even sure if Rust solves this case as far as UB is concerned.

If your entire program is inside unsafe, then Rust is actually worse than C as far as UB is concerned. On the other hand, no one writes Rust like that, and Rust restricts all UB to unsafe blocks.

	▲	cesarb an hour ago \| parent [-]
		> If your entire program is inside unsafe, then Rust is actually worse than C as far as UB is concerned. On the other hand, no one writes Rust like that, and Rust restricts all UB to unsafe blocks. Nitpicking: it's not the unsafe blocks themselves, but a few language features which are only allowed inside unsafe blocks. Language features which are allowed outside unsafe blocks work identically within unsafe blocks, and gain no extra UB just by being inside an unsafe block.

▲

chasil 3 hours ago | parent | prev | next [-]

C is also famously bad at floating point optimization.

Fortran has historcally led this realm (see the Numerical Recipes book).

Julia is a newer option, and I understand that both are commonly used in Python objects.

https://numerical.recipes/

"Read the older 2nd ed. book in Fortran online for free."

	▲	jabl 3 hours ago \| parent \| next [-]
		There are several reasons why Fortran historically has been faster. Many of these are because Fortran is less strict about what the compiler can do so allows optimizations that wouldn't be allowed in C. Such as: - Procedure arguments are not allowed to alias. Similar to restrict pointers in C99+. This is often critical to allow loops to be vectorized, but the onus is on the programmer to ensure no aliasing or else you get UB. - Unspecified evaluation order for expressions. E.g. C requires that "a+b+c+d" be evaluated as "((a+b)+c)+d)" and with floating point it can't do it another way due to rounding. Fortran can do e.g. "(a+b) + (c+d)" where each subterm can be computed in parallel, but again at the cost of slightly different results due to rounding behavior for floats. - Old school Fortran lacked pointers which led programmers to program algorithms using arrays rather than fancier data structures, which cpu's love. In principle there's nothing preventing a competent C or C++ programmer can reach Fortran level performance. In practice, might be difficult. Of course, nowadays performance is much about designing for cache hierarchies (see e.g. "Data Oriented Design") where Fortran doesn't have a built-in advantage.
	▲	mianos 3 hours ago \| parent \| prev [-]
		There is not a lot of floating point in an operating system. The issue with floating point and aliasing preventing vectorisation was from the late 1980s when early C compilers lacked sophisticated alias analysis and standards were loose. is not a really a thing anymore. C can go as fast, specially compiled with strict aliasing. Maybe more work in compilation.

▲

weinzierl an hour ago | parent | prev | next [-]

"And static analysis can only go so far without blowing up compile times."

Compile time is not the main issue with static analysis. It's that C doesn't provide enough information and not the right information to make it efficient and effective.

If you add this info you unavoidably will end up with something looking like Rust.

(Whose long compile times are not caused by its static analysis parts BTW)

▲

jandrewrogers 3 hours ago | parent | prev | next [-]

C is not “high level assembly”. You still need a model of what the code will create. This does not naturally follow from C code. Modern C++ is the most powerful systems language if you care about performance.

While I don’t condone writing new code in C, there are major conceptions about its relationship to performance and C++.

▲

mdspan 3 hours ago | parent | prev | next [-]

Operating systems code can definitely afford runtime checking if it's not too expensive in terms of performance. The Linux kernel has a WARN_ON macro that does exactly this. The tradeoff is worth it in a lot of cases if you're exchanging a small amount of performance for greater debug-ability or security.

▲

imtringued 10 minutes ago | parent | prev [-]

Hot take: The vast majority of UB optimizations in C are just hacks to get around mutable aliasing being the default.