# Discussion about integer overflow

**URL:** https://discourse.julialang.org/t/discussion-about-integer-overflow/69627
**Category:** Internals & Design
**Tags:** numbers, integer-overflow
**Created:** [October 11, 2021, 12:44pm UTC](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627 "2021-10-11T12:44:33Z")
**Posts on this page:** 1
**Showing post:** 104

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [October 13, 2021, 11:15am UTC](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627/104 "2021-10-13T11:15:09Z")

</div>

> [@viraltux](#):
>
> I find more worrying this:
> 
> ```julia
> > julia> 1 / 10^20000
> > Inf
> 
> ```

Because of overflows, and getting rid of them with this idea would be a great _option_:

> [@viraltux](#):
>
> how about implementing a flag for a safe Julia (e.g. `julia --safe)` ?

> [@viraltux](#):
>
> **would just throwing an error also slow down the entire language?**

Doesn’t need to be.\*

> [@GunnarFarneback](#):
>
> has been [discussed](https://discourse.julialang.org/t/a-plea-for-int-overflow-checking-as-the-default/3338) repeatedly, has been implemented in a [package](https://github.com/JeffreySarnoff/SaferIntegers.jl), and finally [Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872).

That was about changing the default, but the default type for integers doesn’t need to change, only the non-default option, so we do not have to wait for Julia 2.0 (only if we change the default later, what I’m not proposing now).

The question is what should replace the default integers, and I’m a bit conflicted, BigInt or SaferIntegers.jl. The argument for the former is that it’s already built into Julia, and it would give a great incentive to optimize it. I know it’s possible (even already done in some package?). Julia has a policy of not adding stuff Julia itself doesn’t need. That would have been an argument to not have BigInt and rationals in the first place… I would personally be ok with adding SaferIntegers.jl as a stdlib (and even removing BigInt if it’s chosen, moved to a package).

People might say you can already just use e.g. SaferIntegers.jl yourself and change the integer literals in the REPL as an option through a package available. But you have to opt into that from the REPL (or rely on package authors to change to an alternative type). I think we should also have the option for scripts, so that end-users can change the default without changing any code.

`*` What I have in mind, is that even if the default for literals would change, we could still use machine integers for stuff that matters e.g. array indexing (or even floats seems to work for JavaScript… I know V8 changes to integers behind the scenes). I’m not arguing for making this option fast right away, just available as a non-default option, that people would actually know about if looking at: `julia --help`

I have my own ideas how to make overflow checks fast, mostly by avoiding them in a lot of cases. Even a compromise of NOT checking for for them for additions only (the most important operation) would go a long way. It hardly ever is the cause of overflowing for 64-bit. That would be multiplying directly or e.g. exponentiation, that can be optimized.

* * *

It’s intriguing what can happen with overflows, already warned against (not exploited, yet?) in C (could hypothetically happen in pure Julia code, and even if it/Julia fixed, because if/since issue at lower level in libc/malloc/calloc not fixed, and could also even happen in (otherwise) safe Java) for (most of?) RTOS operating systems and more: [Multiple RTOS (Update E) | CISA](https://us-cert.cisa.gov/ics/advisories/icsa-21-119-04)

> EXECUTIVE SUMMARY
> 
> - ATTENTION: Exploitable remotely/low attack complexity
> - Vendors: Multiple
> - Equipment: Multiple
> - Vulnerabilities: Integer Overflow or Wraparound

E.g. [BadAlloc Vulnerability Affecting BlackBerry QNX RTOS | CISA](https://us-cert.cisa.gov/ncas/alerts/aa21-229a)

> On August 17, 2021, BlackBerry publicly disclosed that its QNX Real Time Operating System (RTOS) is affected by a [BadAlloc](https://us-cert.cisa.gov/ics/advisories/icsa-21-119-04) vulnerability—CVE-2021-22156. BadAlloc is a collection of vulnerabilities affecting multiple RTOSs and supporting libraries.[[1](https://support.blackberry.com/kb/articleDetail?articleNumber=000082334)] A remote attacker could exploit CVE-2021-22156 to cause a denial-of-service condition or execute arbitrary code on affected devices.[[2](https://support.blackberry.com/kb/articleDetail?articleNumber=000082334)]  
> […]  
> CVE-2021-22156 is an integer overflow vulnerability affecting the `calloc()` function in the C runtime library of multiple BlackBerry QNX products.
> 
> - U.S. Nuclear Regulatory Commission Security Advisory: [Blackberry QNX Vulnerability](https://www.nrc.gov/docs/ML2121/ML21217A177.pdf)

It may be overblown as nuclear reactors shouldn’t have an internet connection?

---

_[View the full topic](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627)._