Hacker News Reader

Comment by hn_submit | Hacker News Reader

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.

View on HN

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

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.

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

Uh, no? If your entire program is inside unsafe then Rust is equal to C.

Rust gets nasty if you want to build safe interfaces around unsafe code because you have to consider every single potential safe interaction (Rust aggressively reorders everything because the aliasing model allows it, in that respect it is "worse" than C but not less safe), whereas with an unsafe caller you're allowed to shrug with your shoulders and tell the higher up caller that it is his problem to figure out, but if you keep handing off to ever higher level unsafe callers, then you are literally back to C levels of unsafety.

If it is not clear, if you use unsafe {} everywhere, you can use *const T, *mut T everywhere. Hence the no aliasing rules don't matter to you at all, which brings us back to the &mut T and &T unsafe-safe interactions between *mut T and *const T. Turning *mut T to &mut T or turning *const T to &T is hard.

This is what makes it so hard to write unsafe code, it's supposed to be usable from a safe interface!

It also explains why static mut was a huge mistake. You cannot take a mutable reference to them. Mutable reference semantics make no sense with static mut.

No they are not equal. There are a lot of hairy details usually around byte layout/endianness that are defined (sometime implementation defined) that are UB or TBDB in rust. Also rust doesn’t have int overflow UB.

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

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

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.

I thought the main advantage had always been the row/column-major order of arrays:

https://en.wikipedia.org/wiki/Row-_and_column-major_order

In short, people solving numerical problems want to write like M[i,j] where i is iterated through on the innermost loop and j is iterated through on the outermost loop... and if the language works in sympathy with them and gets good cache-coherence, that's great, but if the language works against them and would make them write M[j,i] to get the same performance, they don't like it, so they keep writing M[i,j] and let the slowness be the other language's problem.

Nah, that is mostly about keeping the ordering in mind when iterating (e.g. do you iterate first over innermost or outermost index?). And there are algorithms such as (naive) matrix multiplication where the correct order for one matrix is the wrong for the other one, so plus ca change.

But speaking of arrays, one definitive advantage of Fortran is that it has built-in multidimensional arrays in the language. Which is very nice when writing code that needs them. In C many people resort to the Fischer-Price My First Multidimensional Array implementation where they allocate each row separately, which is of course horrible. (In C++ you can use libraries like Eigen or Armadillo which use expression templates and operator overloading to have sensible multidimensional array support even if it isn't built-in.)

Uh... C does have multidimensional arrays. Writing "int a[5][10]" allocates the same contiguous storage as "int b[50]", and accessing a[3][7] will access the integer at ((char *)a) + 3*sizeof(int[10]) + 7*sizeof(int), which would be the same offset as b[37].

It has to be row-oriented because the language allows you to take the address of each intermediate dimension, e.g. int *c = &a[3] gets you a pointer to the equivalent offset of b[30], and legally you can access c[0] through to c[9]. Accessing c[10] would be equivalent to a[4][0] and compilers will let you do it, but I think it's officially undefined behaviour?

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.

> "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, guaranteeing "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 leak out of the sandbox, then that problem must be fixed in the operating system.

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.

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

Why are many individuals here claiming that C isn't "high level assembly"? Anyone that knows the history of Unix and C knows that it is.

Maybe the younger generation is simply ignorant about this.

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

Edit: To be fair for the current topic it's more of an "Inverted Design-by-Contract" issue. The compiler infers the contract via UB instead of exposing it to the developer.

when you divide a/b the contract b != 0 is formed on the function signature, but never made visible. Then someone inevitably violates the invisible contract and all hell breaks loose.

    // What the developer thinks the signature is
    int f(int a, int b);

    // What the compiler secretly changed the signature to
    int f(int a, int b) 
        __attribute__((requires(b != 0))); // The invisible contract!

Reply on news.ycombinator.com