4 ms·
> for example, most of the 25 top software errors don't look like type errors to me, and neither goto fail; nor Heartbleed look like type errors either, Most o
by lelf 12y ago
> for example, most of the 25 top software errors don't look like type errors to me, and neither goto fail; nor Heartbleed look like type errors either,
Most of them do to me. (But I'm coming from Haskell, so it's not only the static typing, it's the very strong one).
Anyway, http://ro-che.info/ccc/17.html http://ro-che.info/ccc/17.html
- bunderbunder 12y agoI'm seeing where a lot of them could be prevented if you set up your types very scrupulously, but I don't think most of them are inherently type errors. That said, I would say that the OP's assertion is itself a type error. The link is a list of "most dangerous" errors, where "most dangerous" is specifically defined as bugs that create security vulnerabilities. This is being used in support of a statement about what the most common bugs are. "Security vulnerabilities" and "software defects" are two different (if related) things, so that's a type error in the argument. And "dangerous" and "common" are two different characteristics, so that's a second type error in the argument.
- dllthomas 12y agoAren't "dangerous" and "common" different values of the same type?
- bunderbunder 12y agoThey might be different subtypes of a supertype called "stuff you should worry about". But not every common error leads to an arbitrary code execution exploit (for example), and not every arbitrary arbitrary code execution exploit is a result of a common error.