kconfiglib handles string literals inconsistently across operating systems
glarsennordic opened this issue · 0 comments
Good afternoon,
Since at least cbf32e2, kconfiglib has inconsistently handled string literals containing the symbol %
Consider the following Kconfig file:
config SOME_CONFIG
string "Some config"
default "AT\%\%SOMECONFIG" if BOARD_SOMEBOARD
On Linux or MacOS, this would produce the following output:
#define CONFIG_SOME_CONFIG="AT%%SOMECONFIG"
Whereas, on Windows, this would be produced:
#define CONFIG_SOME_CONFIG="AT%SOMECONFIG"
Pull Request nrfconnect/sdk-nrf#6570 offers a real-world example of this occurring
The problem was introduced when Kconfiglib switched from its own in-house symbol expansion to using os.path.expandvars
(cbf32e2 is the exact commit in which this was performed).
The problem is that os.path.expandvars, by design, behaves differently on Windows than on Linux or MacOS.
On Windows, %name% expansions are supported in addition to
$name and $ {name}.
This causes inconsistency, under rare circumstances, between Kconfig behavior on Windows vs Linux/MacOS
This could potentially be fixed by importing expandvars
from either the npath
module, or the posixpath
module, instead of directly from os.path
, causing all operating systems to exhibit the same behavior (either the current Windows behavior, or the current Linux behavior, depending on which is chosen).
For example, change
from os.path import dirname, exists, expandvars, islink, join, realpath
to either:
from os.path import dirname, exists, islink, join, realpath
from posixpath import expandvars
or:
from os.path import dirname, exists, islink, join, realpath
from npath import expandvars
The difference being whether to adopt the Windows or the Linux/MacOS behavior as the universal standard. Both are identical, except that in Windows, string literals in the form %VAR%
are also counted as environment variables.