> For the complete documentation index, see [llms.txt](https://docs.zama.org/tfhe-rs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zama.org/tfhe-rs/tfhe-rs/0.5-3/how-to/overflow_operations.md).

# Detect Overflow

TFHE-rs includes a list of specific operations to detect overflows. The overall idea is to have a specific ciphertext encrypting a flag reflecting the status of the computations. When an overflow occurs, this flag is set to true. Since the server is not able to evaluate this value (since it is encrypted), the client has to check the flag value when decrypting to determine if an overflow has happened. These operations might be slower than their equivalent which do not detect overflow, so they are not enabled by default (see the table below). In order to use them, specific operators must be called. At the moment, only additions, subtractions, multiplications are supported. Missing operations will be added soon.

The list of operations along with their symbol is:

| name                                                    | symbol         | type   |
| ------------------------------------------------------- | -------------- | ------ |
| [Add](https://doc.rust-lang.org/std/ops/trait.Add.html) | `overflow_add` | Binary |
| [Sub](https://doc.rust-lang.org/std/ops/trait.Sub.html) | `overflow_sub` | Binary |
| [Mul](https://doc.rust-lang.org/std/ops/trait.Mul.html) | `overflow_mul` | Binary |

These operations are then used exactly in the same way than the usual ones. The only difference lies into the decryption, as shown in following example:

```rust
/// Adds two [FheUint] and returns a boolean indicating overflow.
///
/// * The operation is modular, i.e on overflow the result wraps around.
/// * On overflow the [FheBool] is true, otherwise false

use tfhe::prelude::*;
use tfhe::{generate_keys, set_server_key, ConfigBuilder, FheUint16};

let (client_key, server_key) = generate_keys(ConfigBuilder::default());
set_server_key(server_key);

let a = FheUint16::encrypt(u16::MAX, &client_key);
let b = FheUint16::encrypt(1u16, &client_key);

let (result, overflowed) = (&a).overflowing_add(&b);
let result: u16 = result.decrypt(&client_key);
assert_eq!(result, u16::MAX.wrapping_add(1u16));
assert_eq!(
	overflowed.decrypt(&client_key),
	u16::MAX.overflowing_add(1u16).1
);
assert_eq!(overflowed.decrypt(&client_key), true);
```

The current benchmarks are given in the following tables (the first one for unsigned homomorphic integers and the second one for the signed integers):

| Operation\Size             | FheUint8  | FheUint16 | FheUint32 | FheUint64 | FheUint128 | FheUint256 |
| -------------------------- | --------- | --------- | --------- | --------- | ---------- | ---------- |
| unsigned\_overflowing\_add | 63.67 ms  | 84.11 ms  | 107.95 ms | 120.8 ms  | 147.38 ms  | 191.28 ms  |
| unsigned\_overflowing\_sub | 68.89 ms  | 81.83 ms  | 107.63 ms | 120.38 ms | 150.21 ms  | 190.39 ms  |
| unsigned\_overflowing\_mul | 140.76 ms | 191.85 ms | 272.65 ms | 510.61 ms | 1.34 s     | 4.51 s     |

| Operation\Size           | FheInt8   | FheInt16  | FheInt32  | FheInt64  | FheInt128 | FheInt256 |
| ------------------------ | --------- | --------- | --------- | --------- | --------- | --------- |
| signed\_overflowing\_add | 76.54 ms  | 84.78 ms  | 104.23 ms | 134.38 ms | 162.99 ms | 202.56 ms |
| signed\_overflowing\_sub | 82.46 ms  | 86.92 ms  | 104.41 ms | 132.21 ms | 168.06 ms | 201.17 ms |
| signed\_overflowing\_mul | 277.91 ms | 365.67 ms | 571.22 ms | 1.21 s    | 3.57 s    | 12.84 s   |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zama.org/tfhe-rs/tfhe-rs/0.5-3/how-to/overflow_operations.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.