On Tue, May 28, 2024 at 09:41:47AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
>
> > As I was debugging other Windows-specific issues in a VM already, Chris
> > asked me to also have a look at this issue. And indeed, most of the
> > tests fail deterministically. I also found a fix:
> > ...
> > - setenv("TZ", zone, 1);
> > + _putenv_s("TZ", zone);
> > tzset();
> > }
> >
> > I have no idea why that works though, and the fix is of course not
> > portable. But with this change, the timezones do get picked up by
> > `tzset()` and related date functions as expected.
>
> The header compat/mingw.h already talks about implementing its own
> replacement by making gitsetenv() call mingw_putenv().
>
> gitsetenv() emulates setenv() in terms of putenv(), and on Windows
> mingw_putenv() is what implements putenv(), so the difference you
> are observing is coming from the difference between mingw_putenv()
> and _putenv_s(), I would guess. As the former is isolated within
> compat/mingw.c, it would not involve any additional portability
> issues to redo the former in terms of the latter, I would imagine.
Ah, thanks for the pointer. And indeed, `mingw_putenv()` uses
`SetEnvironmentVariableW()` to provide the functionality. This is what
MSDN has to say [1]:
getenv and _putenv use the copy of the environment pointed to by the
global variable _environ to access the environment. getenv operates
only on the data structures accessible to the run-time library and
not on the environment "segment" created for the process by the
operating system. Therefore, programs that use the envp argument to
main or wmain may retrieve invalid information.
So calling `SetEnvironmentVariableW()` will not affect calls to
`getenv()`. See also issues like for example [2].
This works just fine for us because we also stub out `getenv()` to use
`GetEnvironmentVariableW()`, which is its counterpart. But everything
else in the C runtime that uses `getenv()` will not see the new values,
including our date-related functions. We don't ever set any of those
environment variables though, except for now in this new unit test.
Now the question is why we use `SetEnvironmentVariableW()` over
`_putenv_s`, and whether changing it would be safe. If the answer is a
strict "yes" then we could do that, but if it's a "maybe" then I'd
rather not want to change it just to make these unit tests work. In that
case, we might aim for a localized fix like the one I have posted.
Patrick
[1]: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-wgetenv?view=msvc-170
[2]: https://github.com/curl/curl/issues/4774
Attachment:
signature.asc
Description: PGP signature
