I'm not sure I'm understanding this correctly...

Given the examples, the author wants to ensure that 0 is not a possible input value, and NULL is not a possible output value.

This could be achieved with a simple inline wrapper function that checks pre and post conditions and does abort() accordingly, without all of this extra ceremony

But regardless of the mechansim you're left with another far more serious problem: You've now introduced `panic` to C.

And panics are bad. Panics are landmines just waiting for some unfortunate circumstance to crash your app unexpectedly, which you can't control because control over error handling has now been wrested from you.

It's why unwrap() in Rust is a terrible idea.

It's why golang's bifurcated error mechanisms are a mess (and why, surprise surprise, the recommendation is to never use panic).

▲ integricho 4 days ago | parent [-]

Though is there a significant difference in which is more bad between running into undefined behavior and panic?

▲ kstenerud 4 days ago | parent | next [-]

In C, sure. C is a dangerous language of its time.

But these contracts don't make things better.

Now you're removing control from the user. So now if an allocation fails, you crash. No way to recover from it. No getting an error signal back (NULL) so that you can say "OK, I need to clear up some memory and then try again". (Note that I'm not saying that inline error signaling such as NULL is good design - it's not).

Nope. No error handling. No recovery. You crash. And ain't nothing you can do about it.

That's just bad design on top of the existing bad design. Things that crash your app are bad. No need to add even more.

▲

hdjrudni 4 days ago | parent [-]

I'm not convinced. If something is going to cause a crash, like a nullptr, I'd rather crash near where the error happened with a nice error message, than hitting some UB crash god knows where.

Do I want my app to crash at all? No, of course not. If it's crashing, there's a serious bug. At least now I know where to look for it.

Should we pass back up an error signal instead of crashing? Yes, if it all possible, do that instead. Sometimes it's not possible or not worth the hassle for something you're 99.99999% sure can't/won't happen. Or literally can't currently happen, but you're afraid someone on the project might do a bad refactor at some point 5 years down the road and you want to guard against some weird invariant.

▲

1718627440 4 days ago | parent | next [-]

I think the point is about e.g. malloc as shown in the blog post. The stdlib function already have return values to indicate invalid arguments from the caller. These exist to allow the caller to decide what to do in this case. Replacing them by invoking UB or panicing, means the user looses control.

Having the stdlib expose both ways, means either having two stdlibs (like on MS Windows), or dynamic checks in the stdlib. I don't think either way is a good idea. Thus, these contracts can't be used by libc.

	▲	kstenerud 3 days ago \| parent [-]
		Precisely. The barn door is already open as far as the C library goes. And since C's error mechanism is all in-band (another bad idea in hindsight), the only thing the extra invariant checks will do is add even more (now uncontrollable) crash points to an already intolerably crash-prone app. Panics are like goto: Only useful in VERY rare circumstances. Every use of a panic should require a rock-solid justification for why you're choosing to crash the process - similar to how every call to abort() requires justification in any professional C codebase. assert() in production code was a horrible idea because liberal use was actually encouraged. Rust's panic mechanism was almost good. Unfortunately, they chose to give them all innocuous names like unwrap() rather than or_panic(). So now you have to check for it all the time using clippy because it's too easy for a human to accidentally gloss it over. Linting usually points to a design failure in the language UX.

▲

bluGill 4 days ago | parent | prev [-]

The other hope for contracts is static whole program analysis can prove your program - at least in part. If you can prove some contract false that tells you where a bug is long before anyone triggers it.

▲ ost-ing 4 days ago | parent | prev [-]

Exactly, panicking is a safer way to handle the situation rather than memory access violations

▲ AlotOfReading 4 days ago | parent [-]

Safer in what sense? We have no idea whether this hypothetical code is in a userspace application that can exit safely at any time or a hard real time system where panicking could destroy hardware.

A lot of important programs (like the Linux kernel) don't operate strictly on the exact letter of the standard's UB semantics. They do things like add compiler flags to specify certain behaviors, or assume implementation details.

▲ imtringued 4 days ago | parent [-]

I will never understand how C developers can catastrophize over Rust panics, a language that has a panicless "_try" version of every panic causing function that returns a Result instead, while simultaneously accepting the infinite growth of ever harder to avoid UB in C/C++ and telling people to never have undefined behavior in their code.

If you think dealing with undefined behavior is easy and you assume that people have verified that their software triggers no undefined behavior at runtime is fair game, then you should grant that assumption in favor of Rust developers having done the same with their panics, because avoiding panics is child's play in comparison to avoiding UB.

I don't know what it is about panics that triggers some mania in people. UB does not interrupt the program and therefore allows memory corrupt and complete takeover of a program and the entire system as a consequence. C developers are like "this is fine", while sitting in a house that is burning down.

There used to be a pretty blatant hibernation bug with AMD GPUs on Linux that essentially crashes your desktop session upon turning your computer on from hibernation. I've also had a wifi driver segfault on login that forcibly logged you out so you couldn't login like 9 years ago. C doesn't magically fix these problems by not having an explicit concept of panics. You still need to write software that is correct and doesn't crash before you push an update.

There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.

	▲	AlotOfReading 3 days ago \| parent \| next [-]
		Can we refrain from strawmen? I haven't made any of the points you're harpooning and vehemently disagree with all of them. What I said was that panics aren't always appropriate and the context to determine this doesn't exist at the language level. I didn't say managing UB was easy and in fact I've argued diagnosing it is impossible directly with members of both language committees. I didn't say panics are never appropriate. They usually are appropriate. I didn't say I don't use rust because X, Y, Z. I write rust. Etc. `There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.` More likely, but not guaranteed. I don't want to engage more with you, but there was a specific incident I was thinking of when I wrote the prior post that involved an assert improperly placed in a real time control loop that burnt out a very expensive motor.
	▲	uecker 2 days ago \| parent \| prev [-]
		We removed 30% of UB in the core language already for C2y and are in progress of removing more, so there is no "infinite growth of ever hard to avoid UB". For many UB the right way is indeed to panic and in C you can often achieve this with the UB sanitizer (but not for all).