You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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).
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.
The text was updated successfully, but these errors were encountered:
glarsennordic
changed the title
kconfiglibs handles string literals inconsistently across operating systems
kconfiglib handles string literals inconsistently across operating systems
Jan 25, 2022
Good afternoon,
Since at least cbf32e2, kconfiglib has inconsistently handled string literals containing the symbol %
Consider the following Kconfig file:
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.
This causes inconsistency, under rare circumstances, between Kconfig behavior on Windows vs Linux/MacOS
This could potentially be fixed by importing
expandvars
from either thenpath
module, or theposixpath
module, instead of directly fromos.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
on line 554 of kconfiglib.py
to either:
or:
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.The text was updated successfully, but these errors were encountered: