[Const-me]

Why aren’t you using higher-level memory safe languages for that? In C#, the runtime checks for integer overflow can be enabled with a single compiler switch. The switch is not set by default for some reason, but easy enough to enable manually, a single line in *.csproj file.

If you think GC performance is not good enough, see that proof of concept: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo/Con... That C# code implements parser for Mpeg4 format. That format is way more complicated than GIF or even PDF, yet that code runs fine even on very slow computers (Raspberry Pi 4). There’s another similar one in that project for MKV format.

[snnn]

I'd prefer to catch such errors at compile-time. More static the language is, more optimization/analysis can be made. Sometimes the problem can be simplified when your CPU is 64-bit capable but you limit array sizes to 2GB, then you can use 64-bit math to calculate memory sizes to avoid integer overflow. Java and Google protobuf are two such examples. Sometimes the 2GB limit is acceptable, sometimes it is not. You know protobuf even tries to limit string size to tens of MB for safety? The simplification can not be accepted as a general solution.

Back to your Raspberry Pi 4 example: The CPU is 64-bit, but most users only use 32-bit OS with it. Today most Linux installations are 64-bit. I believe Google doesn't care much on protobuf's security on 32-bit systems. So does the other OSS software. So if you take it seriously, it works but it is not safe(when we are talking integer overflow).

[Const-me]

> I'd prefer to catch such errors at compile-time.

I don't believe it's possible. These integers often coming from user's input, disk, or network. Compiler can't validate these simply because it doesn't have the data.

Even when possible, it's insanely complicated, and computationally expensive, to catch in compile-time, yet very simple in runtime.

Runtime performance overhead is very small because branch prediction is quite efficient on modern CPUs, these branches are almost never taken, JIT compiler knows about that, and emits code which will be predicted correctly even when uncached.

> if you take it seriously, it works but it is not safe

Noy sure I follow. Let's pretend I am taking it reasonably seriously, despite old and unpaid hobby project.

Why it's not safe? The Mpeg4 and MKV parsers are written in C#, and compiled with that <CheckForOverflowUnderflow> option set to True.