Hacker News
points by realharo 3 days ago | 0 comments
>because crypt in musl started returning "*" in some cases some years ago

In Rust, the type of the return value would be a `Result<T, E>`, which means the chain of events that led to this would never have started in the first place.

[–] my-huge-pony 3 days ago
In C the return value would be NULL, except it was changed by musl at some point.

Edit: at the beginning, crypt always returned a value. So hypothetical Rust return type would be a String, and then it would be retained for backward compatibility. Or something else would happen, this is a complex logic bug triggered by a 25 year old chain of events.

[–] realharo 3 days ago
The type of the value in C is `char*`.

That's what led some people to write code where it crashes without checks. Which is still their mistake. But if the type was something that can't be implicitly used like an always-present value, that would have prevented the situation, even with those same people.

[–] uecker 2 days ago
A pointer is a type where a null pointer can't be used as a regular value but leads to a trap when dereferenced.
[–] realharo 1 day ago
By "can't be used as a regular value", I meant that it would be a compile-time error. That you have to explicitly opt into skipping the check, e.g. with `unwrap` in Rust, or with something like `!` in languages where `string` and `string?` are different types (like TypeScript, Kotlin, Swift, C#, etc.)

Trying to change a function return type from e.g. `string` to `string?` would make the backwards-incompatible breaking change immediately visible, and break the builds of all code that relied on not having to check it back when it was `string` - at compile time.

[–] uecker 1 day ago
I see. For safety a run-time check is enough though.

But it turns out one can have a compile-time error forthis in C as well: https://godbolt.org/z/8E9z66cfs

[–] atomicUpdate 2 days ago
You mean could be a `Result<T, E>`. There’s nothing in Rust that forces that.