Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Partially Matching Zig Enums

matklad.github.io

Post reply on HN
Print view View original

101–110 of 170 posts

Re: Partially Matching Zig Enums

#101

Post by uecker »

tialaramex wrote: post #95
uecker wrote: post #91

Earlier quoted context omitted.

And yet, in reality, Rust is also on the "if I am not sure I simply attest that it is fine" side on the fence.

I've been hearing about how I'll inevitably write all this unsafe Rust for... four years now. Some time back I checked and I had written exactly one unsafe block, and so I inspected it again and I realised two things: 1. It was no longer necessary, Rust could now just do this safely. I rewrote it in safe Rust. 2. It was technically Undefined Behaviour, predictably given the chance to shoot myself in the foot that's e…

You are already narrowing this down to only memory safety, which is part one of the Rust fallacies.

Re: Partially Matching Zig Enums

#102

Post by uecker »

pron wrote: post #98
CyberDildonics wrote: post #96

Earlier quoted context omitted.

memory leaks are not considered a safety issue Who told you that? in the Java world we have this thing called "integrity" Your claim was that zig is 'safer' than C++ Zig definitely has safety guarantees around bounds and numeric overflow that C++ doesn't. This can be built in to a class too if someone really wants a bunch of branching in their math. It seems like now safety is being redefined to say that memory leaks…

> Who told you that? There is no one definitive definition of memory safety, but it generally refers to things that can lead to undefined behaviour (in the C and C++ sense), usually due to "type confusion" (or sometimes "heap pollution"), i.e. referencing an address of memory that contains data of one type as if it were another, which can happen due to both bounds or UAF violations. Memory leaks don't cause undefined…

Memory leaks are also a safety issue. Especially not running destructors can be a safety issue, but also a resource leak is at least a DoS. IIRC Rust also included not having memory leaks earlier in their definition of memory safety, but dropped it later.

Re: Partially Matching Zig Enums

#103

Post by uecker »

rowanG077 wrote: post #57
pron wrote: post #48

Earlier quoted context omitted.

> Unless you actually use the simplicity to apply formal methods I don't think simplicity make a language safer. That depends what you mean by "safer", but it is an empirical fact that unsound methods (like tests and code reviews) are extremely effective at preventing bugs, so the claim that formal methods are the only way is just wrong (and I say this as a formal methods guy, although formal methods have come a long…

> That depends what you mean by "safer", but it is an empirical fact that unsound methods (like tests and code reviews) are extremely effective at preventing bugs, so the claim that formal methods are the only way is just wrong (and I say this as a formal methods person) I agree that tests and reviews are somewhat effective. That's not the point. The point is that if you look at the history of programming languages s…

I do not find C code harder to understand than C++ - quite the opposite.

Re: Partially Matching Zig Enums

#104

Post by pron »

uecker wrote: post #102
pron wrote: post #98

Earlier quoted context omitted.

> Who told you that? There is no one definitive definition of memory safety, but it generally refers to things that can lead to undefined behaviour (in the C and C++ sense), usually due to "type confusion" (or sometimes "heap pollution"), i.e. referencing an address of memory that contains data of one type as if it were another, which can happen due to both bounds or UAF violations. Memory leaks don't cause undefined…

Memory leaks are also a safety issue. Especially not running destructors can be a safety issue, but also a resource leak is at least a DoS. IIRC Rust also included not having memory leaks earlier in their definition of memory safety, but dropped it later.

The vast majority of catastrophic problems - nearly all of them, in the grand scheme of things - including those that can cause total system failure or theft of all data are not considered memory safety issues (which is one of the reasons that memory safety is overestimated or at least misunderstood, IMO, and why I prefer to talk about correctness in general). Memory safety refers to a specific kind of problems that correspond to undefined behaviour in C or C++. Memory safety issues are not neessarily any more or less sever than any other program weakness, it's just that for a long time they've been associated with low-level programming.

I'm not aware of any popular language - even a high level one - that prevents memory leaks with any kind of guarantee (although these come in different flavours too, and some kinds are prevented in Java). C/C++/Rust/Zig certainly don't.

Re: Partially Matching Zig Enums

#105

Post by lossolo »

Ygg2 wrote: post #99
hudon wrote: post #73

Earlier quoted context omitted.

I interpreted his post as saying it's not binary safe/unsafe, but rather a spectrum, with Java safer than C because of particular features that have pros and cons, not because of a magic free safe/unsafe switch. He's advocating for more nuance, not less.

Yeah, it's not binary; it's just a step function. /s No, it's as close to binary as you can get. Is your only source of Undefined Behavior FFI specially marked functions and/or packages? Have you checked data races for violating thread safety invariants? If yes - You're safe. Allow a bit of unsafety into the system, like Go, and the unsafety can creep into your ecosystem. See https://www.ralfj.de/blog/2025/07/24/memo…

> Is Go in mostly safer than C++? Maybe

Maybe? You forgot /s there? Asking if Go is mostly safer than C++ is like asking if child proof caps are mostly safer than mason jars for medicine.

> https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Can you show RCE using this? Because, to this day, no one has been able to show me a reasonable program that someone would write and that would result in RCE from "Go memory unsafety" presented in this article. Meanwhile, I can show you thousands of examples and CVEs of how you can easily get RCE using C++.

> Can you prove Rust code is safe? Well there is the simple way - no unsafe. But what about unsafe blocks? Yes, you can prove it for them as well. If the unsafe code block is it will note safety invariants and why are they preserved by unsafe block. Can this be practically done? Depends on the crate, but with enough effort, yes.

You can’t prove Rust code "safe" in the absolute. Safety guarantees apply to safe Rust under the language’s (still evolving) rules, and even then the compiler/backend must uphold them. We still hit unsoundness[1] and miscompiles in safe code (equal pointers comparing unequal... [2]), and the official unsafe code guidelines are not a finalized spec. So documenting invariants in unsafe helps a lot, but it’s not a formal proof, especially across crates and compiler versions.

1. https://github.com/rust-lang/rust/issues/107975

2. https://github.com/rust-lang/rust/labels/I-unsound

On the safety spectrum: C/C++ -> Zig -> Go -> Rust

Re: Partially Matching Zig Enums

#106

Post by tialaramex »

pron wrote: post #97
ViewTrick1002 wrote: post #93

Earlier quoted context omitted.

Which is why there is an effort to formally verify the unsafe use in the Rust standard library. I would also say that unsafe causes a very different human reaction. When like Zig, C or C++ everything is potentially unsafe then you can't scrutinize everything. When submitting a PR in Rust containing unsafe code everyone wants to understand what happens because it is both rare, and everyone are cautious about the dange…

> When like Zig, C or C++ everything is potentially unsafe It is not true that in Zig "everything is potentially unsafe". Zig offers bounds safety, which, BTW, eliminates the most dangerous kind of memory unsafety ( https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html ).

Suppose I have a self-contained Zig project and it has a nasty memory safety bug - how can I identify where the cause might be? What parts of my project source are potentially unsafe ?

You've said it's not everything, so, what's excluded? What can I rule out?

Re: Partially Matching Zig Enums

#107

Post by CyberDildonics »

pron wrote: post #98
CyberDildonics wrote: post #96

Earlier quoted context omitted.

memory leaks are not considered a safety issue Who told you that? in the Java world we have this thing called "integrity" Your claim was that zig is 'safer' than C++ Zig definitely has safety guarantees around bounds and numeric overflow that C++ doesn't. This can be built in to a class too if someone really wants a bunch of branching in their math. It seems like now safety is being redefined to say that memory leaks…

> Who told you that? There is no one definitive definition of memory safety, but it generally refers to things that can lead to undefined behaviour (in the C and C++ sense), usually due to "type confusion" (or sometimes "heap pollution"), i.e. referencing an address of memory that contains data of one type as if it were another, which can happen due to both bounds or UAF violations. Memory leaks don't cause undefined…

the Zig language, just like Rust, guarantees that there are no bounds violations (except in syntactically demarcated unsafe code). C++ just doesn't do that.

You said that already, but when saying zig is safer than C++, pragmatically it isn't because C++ bounds checks in the standard library but zig can never have the automatic resource management that C++ has, and that's what people use all day every day.

Re: Partially Matching Zig Enums

#108

Post by pron »

tialaramex wrote: post #106
pron wrote: post #97

Earlier quoted context omitted.

> When like Zig, C or C++ everything is potentially unsafe It is not true that in Zig "everything is potentially unsafe". Zig offers bounds safety, which, BTW, eliminates the most dangerous kind of memory unsafety ( https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html ).

Suppose I have a self-contained Zig project and it has a nasty memory safety bug - how can I identify where the cause might be? What parts of my project source are potentially unsafe ? You've said it's not everything, so, what's excluded? What can I rule out?

You can rule out a bounds violations from all but specifically marked unsafe code.

Re: Partially Matching Zig Enums

#109

Post by pron »

CyberDildonics wrote: post #107
pron wrote: post #98

Earlier quoted context omitted.

> Who told you that? There is no one definitive definition of memory safety, but it generally refers to things that can lead to undefined behaviour (in the C and C++ sense), usually due to "type confusion" (or sometimes "heap pollution"), i.e. referencing an address of memory that contains data of one type as if it were another, which can happen due to both bounds or UAF violations. Memory leaks don't cause undefined…

the Zig language, just like Rust, guarantees that there are no bounds violations (except in syntactically demarcated unsafe code). C++ just doesn't do that. You said that already, but when saying zig is safer than C++, pragmatically it isn't because C++ bounds checks in the standard library but zig can never have the automatic resource management that C++ has, and that's what people use all day every day.

We keep talking about completely different things. If we're talking about "features that can help reduce some bug" then C++ or Rust have some that Zig doesn't and Zig has some that C++ or Rust don't. Which ends up more pragmatic is an empirical question that's hard to answer without data, but certainly focusing only on what C++ has and Zig doesn't while ignoring what Zig has that C++ doesn't is a strange way to compare things (BTW, I've been programming in C++ for almost 3 decades, and I really dislike RAII and try to avoid it).

But if we're talking about memory safety - which is something very specific - then, for whatever it's worth, Zig is more memory-safe than C++ and Rust is more memory-safe than Zig.

Re: Partially Matching Zig Enums

#110

Post by CyberDildonics »

pron wrote: post #109
CyberDildonics wrote: post #107

Earlier quoted context omitted.

the Zig language, just like Rust, guarantees that there are no bounds violations (except in syntactically demarcated unsafe code). C++ just doesn't do that. You said that already, but when saying zig is safer than C++, pragmatically it isn't because C++ bounds checks in the standard library but zig can never have the automatic resource management that C++ has, and that's what people use all day every day.

We keep talking about completely different things. If we're talking about "features that can help reduce some bug" then C++ or Rust have some that Zig doesn't and Zig has some that C++ or Rust don't. Which ends up more pragmatic is an empirical question that's hard to answer without data, but certainly focusing only on what C++ has and Zig doesn't while ignoring what Zig has that C++ doesn't is a strange way to compa…

We keep talking about completely different things.

You said zig is safer than C++, then to make that argument you keep trying to redefine what safety means to include only features in the language syntax but not done in libraries while saying memory leaks don't matter and automatically freeing memory correctly doesn't matter.

Post reply on HN