Skip to content

fix: prevent integer overflow on 32-bit architectures in helper.size - #2097

Open
josejuanmontiel wants to merge 1 commit into
codenotary:masterfrom
josejuanmontiel:us/32bit_support
Open

josejuanmontiel wants to merge 1 commit into
codenotary:masterfrom
josejuanmontiel:us/32bit_support

Conversation

@josejuanmontiel

Copy link
Copy Markdown

Description

This PR fixes a compilation issue that prevents immudb from being built on 32-bit architectures (such as linux/arm/v6 or linux/arm/v7 used in IoT devices like the Raspberry Pi Zero).

The Issue

In cmd/helper/size.go, unitMap and getUnit() were using the standard int type. In Go, the int type is architecture-dependent (32 bits on 32-bit operating systems).
Since constants like ExaByte (1,152,921,504,606,846,976) heavily exceed math.MaxInt32, the Go compiler catches an overflow and throws a fatal error during the build process:

cannot use ExaByte (untyped int constant 1152921504606846976) as int value in map literal (overflows)

In Go, the size of the `int` type is architecture-dependent (32 bits on 32-bit systems).
The `ExaByte`, `PetaByte`, and `TeraByte` constants defined in `cmd/helper/size.go` exceed
the maximum capacity of a 32-bit integer (2,147,483,647).

This caused an integer overflow during compilation on 32-bit targets like `armv6` or `armv7`
(e.g., Raspberry Pi Zero):
"cannot use ExaByte (untyped int constant 1152921504606846976) as int value in map literal (overflows)"

This commit changes the type of `unitMap` keys and the return type of `getUnit` from `int`
to `int64` to ensure safe compilation across all architectures without altering functionality.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant