On Wed Nov 8 17:21:19 2023 +0000, Piotr Caban wrote:
- What I really want to achieve here is to not break something that is
currently working. If there is any version of msvcrXX that handles unicode environment variables correctly I want to preserve that to avoid regressions. Regarding testing it, if needed, it should be possible to test it with `CreateProcess` call with `lpEnvironment` argument. 2. There's currently no way of sharing the tests (so you will need to copy the tests). Note that I don't think it all needs to be fixed so it's working exactly as in native. My concern is that proposed implementation looks risky in regard to A->W conversion.
sure. I tested how native works and the creation of wenviron and winitenv are done using GetEnvironmentStringsW data, so I'll rewrite accordingly. But this means that the ansi and unicode initenv will be created at different point in time, and could be out of sync. but more importantly, if an env variable is added/updated via kernel API, we will get a difference in the environ / wenviron arrays (it will be absent from environ, but inserted when creating wenviron). so the assumption of keeping the two arrays in sync seems more than fragile (not even speaking of the OOM conditions)