Guide to avoiding vulnerabilities in programming languages [pdf] | Hacker News Reader

Guide to avoiding vulnerabilities in programming languages [pdf]

open-std.org

94 pointsingve9 comments

Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway. Mistakes they would quickly realize if someone pointed it out to them.

Seems to me like safe languages is the real solution to this: make the compiler memorize this document, and have it tell the programmer when he’s made a mistake.

If you’re in the business of writing safety-critical code, relying on humans not making mistakes seems naive at best.

So something like linting for known bad-practice patterns at compile time and failing compilation if at least one is found?

Although it only warns by default IIRC, there is clippy [1] for Rust.

And the current lints: https://rust-lang-nursery.github.io/rust-clippy/current/inde...

[1]: https://github.com/rust-lang-nursery/rust-clippy

edit: damn formatting...

> Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway.

There's some dose of truth to this, but the statement requires further elaboration to illustrate the complete picture. Programmers understand informally and intuitively what to avoid, yet we make serious mistakes when writing code anyway, because we are all stuck at the prerigorous[0] stage of understanding programming languages. Unfortunately, so long as our languages don't have a formal semantics, there is no way to reach the rigorous stage, let alone the postrigorous stage. (There is no path connecting the prerigorous and postrigorous stages that doesn't pass through the rigorous stage.)

[0] https://terrytao.wordpress.com/career-advice/there%E2%80%99s... .

> Seems to me like safe languages is the real solution to this

Safe languages are one solution, perhaps the most useful one in the vast majority of cases. However, legitimate use cases for unsafe languages do exist, and we need workable solutions for those cases. That being said, I don't think an informal English document could be such a solution.

Section 5.4, “Top avoidance mechanisms” (paraphrased):

1. Validate input

2. Check error values

3. Enable compiler static analysis

4. Run a static analysis tool

So, tooling is high on the list. For #1 and #2 tooling may help, but I do not see how it can avoid them.

Lower down that list there are items where tooling will be of limited, if any use, such as “make error handling an integral part of system design”, “use clear and consistent names” and “do not use floating point where integers would suffice”.

The title is incorrect, it's WG23, not WG32.

Is there an explanation for why that happens to even non-dyslexics?

There are tons of explanations. If you want a fancy one: depending on whether you type 23 on the numeric row with your left hand or on the numeric keypad with your right hand, the finger order is reversed.

Exactly. This happens to me frequently.

The ID number is sort of noise in the title anyhow so we'll just take it out.

Reply on news.ycombinator.com