kconfig: prevent out-of-bounds user input for numeric options

Currently, user input of out-of-bounds values for 'int' and 'hex' options
is possible, leading to later silent failures in Kconfig if th

kconfig: prevent out-of-bounds user input for numeric options

Currently, user input of out-of-bounds values for 'int' and 'hex' options
is possible, leading to later silent failures in Kconfig if that value is
used in a comparison, or a warning by GCC or error by Clang if used in the
C code.

Let's factor out the out-of-bounds check on constants, so that it can be
reused for checking user input.

The frontend will now reject an attempted user input of an out-of-bounds
numeric value, similarly to how a value outside the active 'range' already
does.

For migration of existing configurations, a .config file with an
out-of-bounds numeric value will be allowed for now, but will warn the
user when read in by confdata.c

Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-5-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>

show more ...

kconfig: check for out-of-bounds numeric constants

The Kconfig interpreter internally represents constants as strings, then
attempts to parse them as 64-bit signed integers for 'int' options, and
64

kconfig: check for out-of-bounds numeric constants

The Kconfig interpreter internally represents constants as strings, then
attempts to parse them as 64-bit signed integers for 'int' options, and
64-bit unsigned integers for 'hex' options.

However, there is currently no check that the conversion succeeds, leading
to failures when the values are actually used. For example:

config LARGE_INT
int
default 10000000000000000000

config BUGGED_INT_COMPARISON
bool
default y if LARGE_INT < 2

Obviously 10000000000000000000 is larger than 2, but the Kconfig
interpreter will fallback to comparing the two values with strcmp() after
the numeric conversion fails, causing the first character, '1', to be
compared with '2', and giving the wrong result.

Since none of these out-of-bounds values are used as constants anywhere in
the tree, we can already make these error out.

Assisted-by: LLM
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Link: https://patch.msgid.link/20260915211508.291790-3-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor <nathan@kernel.org>

show more ...