https://bugs.winehq.org/show_bug.cgi?id=55835
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
--- Comment #5 from Eric Pouech eric.pouech@gmail.com --- (In reply to blitzkriegoutlaw from comment #4)
It is internal software so not publicly available. I can't state what it is.
Nevermind. It's always interesting to log in bug entry if app is public, so that it can be retested afterwards. When possible.
The unix man page for getenv states: The implementation of getenv() is not required to be reentrant. The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3).
The Microsoft help page has no such note. However, that part of the code compiles and runs on Windows and Linux and I don't have this problem. That unix note probably doesn't apply to Linux as haven't seen the problem there. It wasn't until I tried to run our legacy HMI in Wine that I ran into this problem. Since I have the source code, it wasn't hard to work around the issue by copying the result of getenv into an character array. I believe it is a bug since Windows getenv is reentrant.
yes, msvcrt puts in place a per-entry allocation in _environ (and _wenviron) (so that _environ[i] isn't changed after a putenv if variable isn't stored at location [i])
so, it looks like for native: - (w)getenv("foo") is unchanged (pointer value and pointed string) after (w)putenv calls, iff "foo" variable isn't modified - I would be less confident in the stability of the index inside _(w)environ[]. I haven't tested what happens if one removes a variable at index before i. I fear it could well be that the _(w)environ array is compacted, moving the entry at _(w)environ[i-1].
Anyway, I posted https://gitlab.winehq.org/wine/wine/-/merge_requests/4313 that should solve your issue.