3 ms·

Rather than offer drive-by criticism, perhaps you could illustrate 'the problem' you are suggesting is being hidden?

tmtvl 3y ago
The problem I believe is being discussed is that dereferencing a pointer after the memory it references is freed does not throw a warning at compile time. This means the programmer has to manually keep track of pointers, making sure not to free the relevant memory until there are no more references to it lingering about. While there are programming techniques which to lesser or greater extent prevent problems from occurring, e.g. by allocating all memory needed at the begin of the program and freeing all of it at the end, doing no (de-)allocation while the program is running; such solutions still require some discipline on part of the programmer and for some it is a tall ask.
- k__ 3y ago
  So, Zig set out to solve all but the biggest issue with C?
  - tmtvl 3y ago
    That seems to be what OP is implying. I haven't used Zig, so I can't say. I suppose people who want to avoid memory management related bugs who can't acccept a GC language can use Carp.
  - flohofwoe 3y ago
    The biggest issue with C is arguably buffer overflows, not use-after-free (Zig offers spatial but not temporal runtime memory safety). If you want both, but don't want a Rust-style borrow checker (with all the restrictions this entails), use 'tagged-index-handles', those work just fine across all languages (and even make sense in Rust): https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
pjmlp 3y ago
The problem is that Zig is basically Modula-2 for C syntax lovers, plus metaprogramming. It is hardly safer than Modula-2 already was over C already in 1978. We are in 2023 now.
- renox 3y ago
  You're right, but it doesn't matter: Modula-2 didn't catch up, Zig has a small chance to succeed thanks to its focus on embedded and on its good tooling for cross-compilation.
  - pjmlp 3y ago
    Only makes sense if they fix the remaining security flaws, otherwise it hardly changes the stance that S stands for security in IoT.
dagmx 3y ago
Isn’t that a pretty clear, if terse, description of the problem? Use-after-free is a well known problem in the memory managed programming space and one that Zig infamously does not tackle. For those who aren’t familiar, it’s the use of a resource (a pointer) after it is no longer available for use (or has been freed). Which can in turn result in accidentally accessing unexpected data or crashing.
- psychoslave 3y ago
  I never tried Zig, but can’t you, instead defer the actual resource release, replace it with one which crash at compile time? This is a naive suggestion based on lousy inferences of features that seems highlighted in Zig, comptime and deffer.
  - dagmx 3y ago
    compile time may help for some stuff but if you’re passing pointers to a function, you don’t know what will happen there. You might get a use after free or a double free. Like with all languages, if you’re leaving default safety up to programmer convention, the programmer will let you down eventually. Rust, swift and any language where raw pointers are the exception not the rule (any GC, ref counted or borrowing language really), they all switch the defaults around so that you’re not dealing with memory management yourself unless you absolutely want to.

The problem I believe is being discussed is that dereferencing a pointer after the memory it references is freed does not throw a warning at compile time. This means the programmer has to manually keep track of pointers, making sure not to free the relevant memory until there are no more references to it lingering about. While there are programming techniques which to lesser or greater extent prevent problems from occurring, e.g. by allocating all memory needed at the begin of the program and freeing all of it at the end, doing no (de-)allocation while the program is running; such solutions still require some discipline on part of the programmer and for some it is a tall ask.

k__ 3y ago
So, Zig set out to solve all but the biggest issue with C?
- tmtvl 3y ago
  That seems to be what OP is implying. I haven't used Zig, so I can't say. I suppose people who want to avoid memory management related bugs who can't acccept a GC language can use Carp.
- flohofwoe 3y ago
  The biggest issue with C is arguably buffer overflows, not use-after-free (Zig offers spatial but not temporal runtime memory safety). If you want both, but don't want a Rust-style borrow checker (with all the restrictions this entails), use 'tagged-index-handles', those work just fine across all languages (and even make sense in Rust): https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html

pjmlp 3y ago

The problem is that Zig is basically Modula-2 for C syntax lovers, plus metaprogramming. It is hardly safer than Modula-2 already was over C already in 1978. We are in 2023 now.

renox 3y ago
You're right, but it doesn't matter: Modula-2 didn't catch up, Zig has a small chance to succeed thanks to its focus on embedded and on its good tooling for cross-compilation.
- pjmlp 3y ago
  Only makes sense if they fix the remaining security flaws, otherwise it hardly changes the stance that S stands for security in IoT.

dagmx 3y ago

Isn’t that a pretty clear, if terse, description of the problem? Use-after-free is a well known problem in the memory managed programming space and one that Zig infamously does not tackle. For those who aren’t familiar, it’s the use of a resource (a pointer) after it is no longer available for use (or has been freed). Which can in turn result in accidentally accessing unexpected data or crashing.

psychoslave 3y ago
I never tried Zig, but can’t you, instead defer the actual resource release, replace it with one which crash at compile time? This is a naive suggestion based on lousy inferences of features that seems highlighted in Zig, comptime and deffer.
- dagmx 3y ago
  compile time may help for some stuff but if you’re passing pointers to a function, you don’t know what will happen there. You might get a use after free or a double free. Like with all languages, if you’re leaving default safety up to programmer convention, the programmer will let you down eventually. Rust, swift and any language where raw pointers are the exception not the rule (any GC, ref counted or borrowing language really), they all switch the defaults around so that you’re not dealing with memory management yourself unless you absolutely want to.