On Wed Nov 8 17:05:16 2023 +0000, Piotr Caban wrote:
There's one more thing that the MR changes that needs addressing. We no longer use GetEnvironmentStringsW and depend on A->W conversion. It would be good to test what happens with variables that can't be correctly represented in ansi case. It's also interesting to check what happens when there are duplicated variable names due to conversion error. I would also like to make sure it doesn't introduce regression in ucrtbase (assuming it handles it differently).
on the first point, I'd rather first test how \_winitenv is constructed. I derived it from \_environ[], but it could also well be directly from GetEnvironmentStringsW (using same logic as how \_initenv is created) (*). If it's the case, that would likely solve the question about unicode variable names. (not sure yet if such a test can be kept around init testing, but I was thinking of something like: SetEnvironmentVariableW("foo"n "bar") before winitenv is created and check afterwards if foo is present in \_winitenv or \_wenviron, then it means it's derived from kernel data; otherwise from _environ[]).
for ucrtbase, I started looking at it. all the 4 env (ansi & unicode) + init seem to be created at startup (when dynamic linking ucrtbase, didn't try with static linking on MSVC). That's one difference from msvcrt (but this MR doesn't change this behavior). What's the best practice for sharing the tests between msvcrt and ucrtbase? (tests need adaptation as some APIs like __getmainargs doesn't exist in ucrtbase)