There were different syntaxes for hashes and non hashes. The problem was that both a non hash "this password isn't set" and a non hash "this call to crypt produced an error" used the same non password value.
I think the argument would be that in C people will look at a char* and think "string" rather than "string or null". Thus consumers of the library not checking the result and the maintainer trying to be helpful by putting a "safe" value in there for the error case.
Whereas if the library returns something that is unambiguously an option type, consumers unambiguously call unwrap at their own risk.
Of course you do have a point (assuming I'm picking up what you're suggesting correctly) that all pointers in C are option types. But I think there's a cognitive ergonomics aspect to this where an option type more clearly relays the library authors' intent.
First you shouldn't have unwraps in prod code, and you can verify that in your CI/build process/whatever. Second, now you have a crash of the SSH server, which is arguably much better than some random logging in as root.
This isn't about "you", it's about whether any consumer of your code is using unwrap on the result, which currently is perfectly safe to do. The equivalent in C is returning NULL, which would also have caused a crash. They decided not crashing was preferable, which is how we ended up here.
"you shouldn't have unwraps in production code" is exactly the same form of argument as "you shouldn't be assuming crypt returns a valid non-null pointer in production code".
Absolutely not. Unwrap is a language rule, so everyone knows unwrap is not a safe thing to do and writing it even once is an explicit dismissal (and you should document it). On the other side, knowing that crypt does not necessarily return a hash is easily overlooked and forgotten, there is no code smell that can hint you that you are doing things wrong.
I don't really care about the form of the argument when the concrete results are that (i) “no unwrap in prod” is trivial to ensure through the toolchain, (ii) even though, its consequences are “damn it crashed” instead of “welp I guess this guy is root now”.
In this situation, the decisions to make crypt implementations stop returning null in favor of a string error token were made not because C programs that misuse crypt are difficult to fix, but because they are in the form of unknown binaries in the wild that you cannot fix.
And that analogous situation can happen in the safer language where crypt returns an Optional(String) which some bad programs assume is always present. You don't know where all such programs exist, and people use them who don't have the code and cannot fix them.
Returning an error token which is carefully different from crypt's second argument was an attempt to fix programs that cannot be hunted down, patched and recompiled, even if fixing them would be easy to do.
Of course the tooling for C pointers being null or not is not comparable to optional types; that's not debatable.
> And that analogous situation can happen in the safer language where crypt returns an Optional(String) which some bad programs assume is always present.
Once again, no, because these unknown programs would just crash on the `.unwrap()`; not get in a silently corrupted state. Same causes, different effects.
I cant give codex an intercom to other sessions or use a “ask gemini” like extension because it will immediately ask every question it can to another session and will frame its task as a question just to get Gemini to do it whilst it just sits idle lmao
Could be 4 screens overlapping each other. Pull the corners and the lower screens pull out from below the upper ones. There would be a visible seam at the boundary, but maybe there's a trick you could use to disguise it.
Cloudflare has no part in this beyond providing the technology. There are various alternative "security check" pages that are used by others; cloudflare's is the best of the bunch IMO, though still annoying.
This page isn't cloudflare's, cloudflare stopped using google's captcha some years ago. It says ray id at the bottom, idk what's up with that, but it's clearly different.
I got banned on cloudflare yesterday for refreshing the a page too many times during a failed "human check" and am still bitter about it. You are 100% correct though, this isn't cloudflare. I still stand by the point though. Having massive consolidation in the space is dangerous.
50,000 tokens later (amounting to $74 in actual inference costs after IPOs in '27) and we can finally open a webpage that looks like it was designed in the 90's and using SingleFile plugin weighs in at 410KB. Another successful day browsing the World Wide Web.
FDE without TPM requires the passphrase to have as many bits of security as you want the encryption to have. With a TPM you can have something as short as a PIN, since the TPM can limit the rate at which password attempts are made. I assume most users are satisfied with the weak security implied by a short passphrase, but a dedicated attacker could likely crack it.
FDE uses a key derivation function to limit the rate at which offline password attempts can be made. Not as limited as a TPM can be but not unlimited either and you can adjust it depending on how long you want to wait every time you unlock.
Good news! Apple is still permitted to vet apps for security reasons, even when they are distributed on alternative app stores. So you can keep downloading apps with confidence, wherever they come from.
This is just for new mexico, a relatively small state in a single country facebook operates in. It's probably a solid decade worth of profit in that state. Because their privacy policy that no one reads wasn't clear enough.
reply