Follow-up Comment #12, bug #8807 (project wesnoth):
Okay, I've searched the web and I may have found a reason putenv and
SetEnvironmentVariable could be subtly different.
It could be that putenv and getenv still offer support for _environ and envp.
(_environ is deprecated, not sure about envp.) These are declared non-const
(even though writing to them would be a really bad idea) but the environment
block in Windows is to be treated as read-only according to the
documentation.
So maybe the CRT gets a copy of the environment, and putenv modifies to copy
in sync with its calls to SetEnvironmentVariable. And maybe getenv reads from
the copy, rather than the real environment.
If so, it explains why skipping the second call (LANGUAGE=French) works: it is
never seen by getenv, which still thinks LANGUAGE=fr_FR. It would also mean
that I must have made a mistake trying to skip the call to putenv, but I have
no time to test this right now.
(If this is the case, calling getenv is dangerous, since it doesn't read the
real environment, which could pose a problem in the presence of non-C[++]
libraries or native Win32 libraries which may change the environment.)
But this is all just hypothetical until I can confirm it.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?8807>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
