Hacker News
points by bvinc 4 days ago | 0 comments
> Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.

Certainly safer, but not memory safe. Operations as simple as multiplying signed integers or popping an empty vec can be undefined behavior which is not memory safe.

[–] smallstepforman 4 days ago
For most domains, it is fine. Why should my valued checked code pay the price for checking every arithmetic operation for overflow. Why should my correctly implemented algorithm waste CPU checking something I know is valid? And worst of all, what happens when a logic error is encountered, we run untested code path? I hate code that is conditionally defensive (eg. if (ptr) ptr->critical(); ). I should never be in that situation, a silent ignore corrupts internal state, and never tested the fail path. Ptr may even refer to garbage. Its a stupid defebsive check in 90% of code bases. std::optional<Ptr> at least clarifies intent.
[–] crote 4 days ago
The problem is that it silently overflows by default - and a good chunk of the time it is even undefined behavior. Sure, in some situations you as the developer are 100% certain that an overflow is impossible (despite the compiler not being able to prove this and therefore eliminate the checks), but in the vast majority of cases it is a footgun silently waiting to go off.

Rust tries to solve this by having basic addition panic in debug, while silently-but-consistently continuing in production: overflow is considered a bug, but it is at least not a platform-dependent bug.

If overflow is expected, then there's checked_add to detect it and fail in a friendly way, saturating_add / wrapping_add / carrying_add for specific overflow behavior.

Finally, if speed is crucial and overflow is either impossible or you don't care about the outcome whatsoever, there's unchecked_add to explicitly opt-in to a C-like "just do whatever the machine feels like".

You can still do everything you can with C. It it just an explicit choice, rather than an implicit platform-dependent mechanism you might forget about.

[–] tialaramex 4 days ago
> unchecked_add to explicitly opt-in to a C-like "just do whatever the machine feels like".

Just like for signed integers in C the {integer}::unchecked_add is Undefined Behaviour if overflow occurs. So that's not "whatever the machine feels like" it's much worse.

This is an unsafe function, so you're expected to write a SAFETY rationale for the unsafe call, and that's your opportunity to justify to a future maintainer why you were sure this addition never overflows. If you find yourself struggling to justify that belief it probably means you should not have used this function.

If you're going to write guard code for overflows, and use that to justify the SAFETY claim, why not use the existing functions for that? Clippy will suggest this in many cases because it's less likely you will blow your own foot off.

[–] Maxatar 3 days ago
No one is suggesting that every arithmetic operation is checked for overflow. The suggestion is that overflow is not undefined behavior. Getting rid of undefined behavior for overflow does not in anyway require that every operation is now checked, all it requires is specifying that the result of an arithmetic overflow depends on the platform and different platforms might produce different results.
[–] dwattttt 3 days ago
Defining the behaviour for overflow in the language doesn't suddenly mean the behaviour is what every program wanted. Fine that it has a defined result, but if that result isn't what you meant when you wrote a+b it's still a bug.

At a broad view, we get to a place where there's no "bug" when "what happens on overflow" is what the program(mer) wants.

[–] Maxatar 3 days ago
I have no idea how to parse your comment or how it relates to what I said.

All I said is that you can remove undefined behavior from signed overflow without having to introduce checks to every arithmetic operation and without having to specify any particular behavior or outcome. The technical term for this is "unspecified behavior" and the consequence of making overflow unspecified behavior is that the consequences of overflow, while still unspecified, must be bounded in space and time, unlike undefined behavior whose consequences are not required to be bounded in either space or time.

[–] dwattttt 3 days ago
I mean removing undefined behaviour from signed overflow isn't the problem. The problem is that when a programmer previously wrote a signed operation that could overflow, they didn't specify what behaviour they really needed.

You can define a behaviour today that they'll all get, but you can't define a behaviour that matches what each programmer needed when they wrote their operation. Some of them can wrap safely. Some of them would need to saturate. Others would need it to abort.

The problem isn't that the behaviour is undefined per se, it's that you can't tell afterwards which potential behaviour the programmer needs, and choosing one behaviour e.g. wrap will break everyone who actually needed saturating, or trapping, etc.

[–] UFxESTER 4 days ago
I like the Employees Wash Hands sign. Recent batches of API tools seem focused on sanitizing IO: WebMCP, AI strings, safe native input parse, even Assembly mapping. So in a hot loop (whatever F35 anonymous lambda) you may have data change under you. So on antiquated hardware (like a Voyager I) maybe you want to flash the firmware to 3.5 after 70 years... but Iran has a HELLIOPARSER. It's imperative to be defensive transmitting data streams across the light years.