←back to thread

The world could run on older hardware if software optimization was a priority

(twitter.com)
838 points turrini | 3 comments | 13 May 25 10:31 UTC | HN request time: 0.001s | source
Show context
titzer ◴[13 May 25 12:05 UTC] No.43971962[source]▶
I like to point out that since ~1980, computing power has increased about 1000X.

If dynamic array bounds checking cost 5% (narrator: it is far less than that), and we turned it on everywhere, we could have computers that are just a mere 950X faster.

If you went back in time to 1980 and offered the following choice:

I'll give you a computer that runs 950X faster and doesn't have a huge class of memory safety vulnerabilities, and you can debug your programs orders of magnitude more easily, or you can have a computer that runs 1000X faster and software will be just as buggy, or worse, and debugging will be even more of a nightmare.

People would have their minds blown at 950X. You wouldn't even have to offer 1000X. But guess what we chose...

Personally I think the 1000Xers kinda ruined things for the rest of us.

replies(20): >>43971976 #>>43971990 #>>43972050 #>>43972107 #>>43972135 #>>43972158 #>>43972246 #>>43972469 #>>43972619 #>>43972675 #>>43972888 #>>43972915 #>>43973104 #>>43973584 #>>43973716 #>>43974422 #>>43976383 #>>43977351 #>>43978286 #>>43978303 #
justincormack ◴[13 May 25 12:26 UTC] No.43972135[source]▶
Most programming languages have array bounds checking now.
replies(1): >>43972762 #
oblio ◴[13 May 25 13:30 UTC] No.43972762[source]▶
Most programming languages are written in C, which doesn't.

Fairly sure that was OP's point.

replies(1): >>43986597 #
1. ryao ◴[14 May 25 16:42 UTC] No.43986597[source]▶
Secure string handling functions like strlcpy() and strlcat() do have bounds checks. Not everyone uses them sadly.
replies(1): >>43988353 #
2. oblio ◴[14 May 25 19:34 UTC] No.43988353[source]▶
And that again, is the point. That stuff should be built-in and almost non-negotiable. It should be a lot more work to do the unsafe thing (see: Rust).
replies(1): >>43988550 #
3. ryao ◴[14 May 25 19:55 UTC] No.43988550[source]▶
They are negotiable in Rust too. Just use the unsafe keyword everywhere. If you want to use a language where they are non-negotiable, use JavaScript.

Secure string functions are built into C these days. The older error prone ones are as well. You can ban the older functions from code bases, but it is hard to justify outright bans for all of them. If you audit string function usage in a non-trivial codebase, you likely will find instances where the old, error prone, string functions are used in safe ways and leaving them alone makes sense. This is particularly the case when constant length strings are used with constant length buffers. Here is an example where the old string functions are just as safe as the secure string functions:

https://github.com/openzfs/zfs/blob/master/etc/systemd/syste...

I found it when I audited the string function usage in OpenZFS with the goal of removing all uses of the older string functions. While I replaced every instance old string function where the secure string functions mitigated even the slightest risk, I could not bring myself to remove these, since there was nothing wrong with them. After my patches, a few string functions were then banned from the codebase with a build system hack put in place to break the build process if someone tried to reintroduce the banned functions.