Kconfiglib icon indicating copy to clipboard operation
Kconfiglib copied to clipboard

kconfiglib handles string literals inconsistently across operating systems

Open glarsennordic opened this issue 2 years ago • 0 comments

Good afternoon,

Since at least cbf32e29a130d22bc734b7778e6304ac9df2a3e8, 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 https://github.com/nrfconnect/sdk-nrf/pull/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 (cbf32e29a130d22bc734b7778e6304ac9df2a3e8 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

on line 554 of kconfiglib.py

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.

glarsennordic avatar Jan 25 '22 22:01 glarsennordic