|
From: Earnie Boyd <earnie_boyd@...>
Subject: Re: Re: SetEnvironmentVariableA & getenv Newsgroups: gmane.comp.gnu.mingw.user Date: 2003-07-30 13:52:02 GMT (11 years, 39 weeks, 4 days and 33 minutes ago) Sam Steingold wrote: >>* In message <Law11-OE43sebmspH2q0000a664@...> >>* On the subject of "Re: SetEnvironmentVariableA & getenv" >>* Sent on Wed, 30 Jul 2003 09:26:06 +0800 >>* Honorable "Luke Dunstan" <coder_infidel@...> writes: >> >> >>>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" >>>(gdb) >> >>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? > <quote> Remarks 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. </quote> ------------------------------------------------------- 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. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ MinGW-users mailing list MinGW-users@... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|