Can you say more about spatial security v.s. temporal security and how Zig does them?

Spatial memory safety means that a language (at least in its subset that's designated "safe") doesn't allow you to manufacture pointers into memory that may contain data of a different type than what's expected by the pointer (we'll call such pointers "invalid"). The classic examples of spatial memory safety is guaranteeing that arrays are never accessed out of bounds (hence "spatial", as in pointers are safely constrained in the address space). Zig guarantees (except when using delineated "unsafe" code) such spatial safety.

Temporal memory safety is the guarantee that you never access pointers that have been valid at some point in time after they've become invalid due to reallocation of memory; we call such pointers "dangling" (hence "temporal", as in pointers are safely constrained in time). The classic example of this is use-after-free. Zig does not guarantee temporal safety, and you can accidentally have a dangling pointer (i.e. access a one-time valid pointer after it's become invalid).

Invalid pointers are especially dangerous because, in languages where they can occur, they've been a very common source of exploitable security vulnerabilities. However, violating spatial memory bounds is more dangerous, as the result is more easily exploited by attackers in the case of a vulnerability, as it's more predictable.

> So Zig is as expressive as C++. but not only safer, but also much simpler, and compiles faster

Tbh syntax-wise Zig feels more cryptic[1] at first than C++.

[1] e.g. `extern "user32" fn MessageBoxA(?win.HWND, [*:0]const u8, [*:0]const u8, u32) callconv(win.WINAPI) i32;` from https://ziglang.org/learn/samples/

I think that's just a matter of syntax habits, presumably because you're already familiar with C++ syntax. The syntax in your example is especially "cryptic" simply because it's an FFI signature (of a function that's not written in Zig and doesn't use the normal Zig data representations).

To be clear the equivalent C++ code is:

    #include <windows.h>
    extern "C" __declspec(dllimport) int __stdcall MessageBoxA(HWND, LPCSTR, LPCSTR, UINT);
    // or
    extern "C" __declspec(dllimport) int __stdcall MessageBoxA(void *, const char[], const char[], unsigned int);

It's not exactly a stellar improvement.

Lol, no this is the equivalent

  #include <windows.h>

 int main() {
      MessageBoxA(NULL, "world!", "Hello", 0);
      return 0;
  }

I guess this must vary by usecase, but in the Linux kernel work I do, expressiveness is just not an issue. C is a dumb language, it's fine. Coding is just such a small part of the engineering task. Schlepping to write nontrivial stuff in C can be a drag but it's just such a minor thing compared to the task of getting OS software designed correctly that I am not really excited about trying to improve on that axis.

Whereas the memory safety issue is totally fundamental and totally terrifying. There's no other way to solve it than with a new language. The cost of changing languages is staggering but we have no choice. Yet... Paying that cost and not eking out the maximum safety benefit that's practical... Seems a bit dodgy to me.

> There's no other way to solve it than with a new language.

That's not true, though. If memory safety is the only thing that you need and C doesn't have, there are products that offer memory-safety proofs for C (e.g. https://www.trust-in-soft.com). You do need to add some lifetime annotations and may want to change your code here and there, but it's overall much cheaper than a rewrite in a new language. I believe such solutions are more popular, too; few companies - even and especially those that care primarily about correctness - are crazy enough to justify a rewrite of an existing product just for memory safety.

> Paying that cost and not eking out the maximum safety benefit that's practical... Seems a bit dodgy to me.

The cost is not the same, though (and if you only consider rewrites, as I said, there are better options). It sounds like you're saying that any cost is worth any added safety. I don't think that's true, but if it were, then something like ATS is probably what you're after (it isn't, though, because it's practically nobody's choice). Anything short of that is some compromise between cost and safety. Rust's compromise is just different from Zig's. They're both significantly safer than C and a far way off from ATS. Everyone seems to agree that the sweet spot is somewhere on that spectrum - not C, not ATS - but there's no agreement on where.

> there are products that offer memory-safety proofs for C

what does the c checked by this tool look like? for an example like https://play.rust-lang.org/?version=stable&mode=debug&editio... , does the tool accept the assignment with f and reject the assignment with g?

That particular code is shaped by Rust's specific scoping an lifetime rules, but generally - yes (provided you offer annotations for things the tool can't infer). Some changes to the code may be needed to make things easier, but it's still a lot cheaper than a rewrite in a different language.

in this example, aren't the scoping rules for c pretty much the same?

what do the annotations for the tool look like? is the analysis local, in that it doesn't look into the bodies of other functions? if it is, surely you would have to have lifetimes and be generic over them.

how much c code satisfies the tool? if there's hardly any c satisfying the tool, there might actually be a larger ecosystem of rust code to use.

So the annotations for such tools are pre/post conditions for certain properties (say, pointer validity, ownership). Like types, function annotations can sometimes be inferred, or they may need to be explicit. Once that information is known about a function, there's no need for the tool to look inside it again when analysing callers.

If you want to get a sense of what that may look like, see https://www.frama-c.com (which is a community project, so maybe not as smooth and polished like more professional tools).

Well, Frama-C is maintained thanks to public funding (Europe/France) and industrial users who use it for actual certification of systems. For example, Thales (Common Criteria EAL7), Airbus (DO-178C), EDF (ISO 60880). I don't know what you mean by professional tool if this is not professional ;)