Sam Steingold wrote:
>>* In message
>>* On the subject of "Re: SetEnvironmentVariableA & getenv"
>>* Sent on Wed, 30 Jul 2003 09:26:06 +0800
>>* Honorable "Luke Dunstan"
>>>modification of environment with SetEnvironmentVariableA() is not
>>>picked up by getenv():
>>>(gdb) p SetEnvironmentVariableA("FOO","BAR")
>>>$1 = 1
>>>(gdb) p getenv("FOO")
>>>$2 = 0
>>>(gdb) p GetEnvironmentVariableA("FOO",value,10)
>>>$3 = 3
>>>(gdb) p value
>>>$4 = 0x22b358 "BAR"
>>No, it is just how MSVCRT works so it is not specific to MinGW
>>either. The documentation for _putenv() says that you should not
>>modify the environment "directly" (i.e. using
>>SetEnvironmentVariable). Basically the C runtime maintains a set of
>>environment variables separate from the OS environment.
> This is confusing.
> Are you saying that each process has two sets of environment variables?
> Actually, MSDN does not document getenv() at all.
> Could you please elaborate?
The getenv function searches the list of environment variables for
varname. getenv is not case sensitive in Windows 98/Me and Windows
NT/2000/XP. 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.
_wgetenv is a wide-character version of getenv; the argument and return
value of _wgetenv are wide-character strings. The _wenviron global
variable is a wide-character version of _environ.
In an MBCS program (for example, in an SBCS ASCII program), _wenviron is
initially NULL because the environment is composed of
multibyte-character strings. Then, on the first call to _wputenv, or on
the first call to _wgetenv if an (MBCS) environment already exists, a
corresponding wide-character string environment is created and is then
pointed to by _wenviron.
Similarly in a Unicode (_wmain) program, _environ is initially NULL
because the environment is composed of wide-character strings. Then, on
the first call to _putenv, or on the first call to getenv if a (Unicode)
environment already exists, a corresponding MBCS environment is created
and is then pointed to by _environ.
When two copies of the environment (MBCS and Unicode) exist
simultaneously in a program, the run-time system must maintain both
copies, resulting in slower execution time. For example, whenever you
call _putenv, a call to _wputenv is also executed automatically, so that
the two environment strings correspond.
Caution In rare instances, when the run-time system is maintaining
both a Unicode version and a multibyte version of the environment, these
two environment versions may not correspond exactly. This is because,
although any unique multibyte-character string maps to a unique Unicode
string, the mapping from a unique Unicode string to a
multibyte-character string is not necessarily unique. For more
information, see _environ, _wenviron.
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
MinGW-users mailing list
You may change your MinGW Account Options or unsubscribe at: