<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/scripts/kconfig/tests/err_num_mismatch, branch master</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>kconfig: check for hex and int mismatches</title>
<updated>2026-09-17T23:31:00+00:00</updated>
<author>
<name>Julian Braha</name>
<email>julianbraha@gmail.com</email>
</author>
<published>2026-09-15T21:15:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d13bad83d89d1022fee254c08f6e01084eb4395e'/>
<id>d13bad83d89d1022fee254c08f6e01084eb4395e</id>
<content type='text'>
Using a numeric option of one type (e.g. 'int') to determine the value of
a different numeric type (e.g. 'hex') currently fails silently in various
ways if attempted, because the underlying string representation is naively
reused.

Example 1:

  config I
    int
    default -1

  config HEX_DEFAULT_INT
    hex
    default I

Here, HEX_DEFAULT_INT actually gets set to '0x-1', which is of course not
a valid hex value.

Example 2:

  config H
    hex
    default A

  config INT_DEFAULT_HEX
    int
    default H

Here, INT_DEFAULT_HEX actually gets set to 'A', without even converting
into the base-10 equivalent of 10. This value, 'A', is otherwise a
rejected int value if entered in the frontend, or read in from an existing
.config file.

These int-hex mismatches currently do not appear anywhere in the tree, so
it is already safe to make these error out.

Assisted-by: LLM
Signed-off-by: Julian Braha &lt;julianbraha@gmail.com&gt;
Reviewed-by: Nicolas Schier &lt;n.schier@fritz.com&gt;
Link: https://patch.msgid.link/20260915211508.291790-4-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Using a numeric option of one type (e.g. 'int') to determine the value of
a different numeric type (e.g. 'hex') currently fails silently in various
ways if attempted, because the underlying string representation is naively
reused.

Example 1:

  config I
    int
    default -1

  config HEX_DEFAULT_INT
    hex
    default I

Here, HEX_DEFAULT_INT actually gets set to '0x-1', which is of course not
a valid hex value.

Example 2:

  config H
    hex
    default A

  config INT_DEFAULT_HEX
    int
    default H

Here, INT_DEFAULT_HEX actually gets set to 'A', without even converting
into the base-10 equivalent of 10. This value, 'A', is otherwise a
rejected int value if entered in the frontend, or read in from an existing
.config file.

These int-hex mismatches currently do not appear anywhere in the tree, so
it is already safe to make these error out.

Assisted-by: LLM
Signed-off-by: Julian Braha &lt;julianbraha@gmail.com&gt;
Reviewed-by: Nicolas Schier &lt;n.schier@fritz.com&gt;
Link: https://patch.msgid.link/20260915211508.291790-4-julianbraha@gmail.com
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
