setenv()
Locked
 
|
|
In reply to this post by Anton Shepelev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 On 15/11/16 21:46, Anton Shepelev wrote: > Is the setenv() function from stdlib.h supposed to work in > MinGW? Short answer: no. Explanation: 1) MSVCRT.DLL exports putenv(), (strictly _putenv(), but MinGW defines an import library alias with the POSIX.1-2008-XSI compatible name), which is semantically similar to the Unix System V function of the same name. However, there is no setenv(), nor any semantically similar API, provided by any Windows DLL. 2) Neither putenv(), nor setenv() is required by ISO-C, so, even though both are specified by POSIX, it isn't considered imperative for MinGW to provide what isn't already provided by MSVCRT.DLL. > When I compile the following program: > > #include <stdlib.h> int main( int argc, char** argv ) { > setenv("test", "1", 1); return 0; } > > I get: > > cco6C8tG.o:test.c:(.text+0x26): undefined reference to `setenv' > collect2.exe: error: ld returned 1 exit status Expected. C generates an implicit function prototype, at compile time, but fails at link time, because no such API is available. There are two possible solutions, which you could consider: 1) Modify your source, as Eli has suggested, to use [_]putenv() 2) Draw inspiration from the attached modification to your original sample code, to implement setenv(), (or, if you raise a feature request on the issue tracker, I may consider adding it for the next mingwrt release). > If [I] change the file extension to cpp, the error is different: > > test.cpp: In function 'int main(int, char**)': test.cpp:3:24: > error: 'setenv' was not declared in this scope { setenv("test", > "1", 1); Again, expected; because setenv() is not implemented, <stdlib.h> does not furnish a prototype, and you're now compiling as C++, which MUST have a declaration in scope at compile time ... C++ will NOT infer one implicitly, so this becomes a compile time failure. > And where is stdlib.h located? I couldn't discover it using: > > find / -name stdlib.h Strange; if you have mingwrt properly installed, (as it MUST be for GCC to work at all), it should be in $MINGW_ROOT/include, (where $MINGW_ROOT represents the root of your installation tree ... gcc.exe itself will be installed as $MINGW_ROOT/bin/gcc.exe - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYLHOAAAoJEMCtNsY0flo/vmMQAIx4dZkut0wxu5RFHxHhmZ0Y LPvK+6K3veLlRceX/KSXAtno4mp3tWGT50OUwAmB3VyJ6SHJvuFg9cL+P6fqC0/j mO976093wpUerrk1QBpC9J1lZVYSRkSpD4MHfKrhQ5SRc9ifaDog06PbLYBOG7Q5 fpc/C893ZL49yqni7D6W6KvVZyTtcyA4tyCdQY99bqnGSdZArck3hkqKZq6EhwH0 6UyDMgZgRucXqWYy/XZxg2kfpDsuWrNzELFk/wSLcSGTdLDnjTpV/PuFV+HR+d8h i1wHShyfcuAUKpCg7vp75yH+BgpiVWBnwHA1P9mabkKAJYQly3dOFn0UIuJ/MstC IQoBrmAili6dnp/ADtLP9aI87wRd9XckeuPAmL0MAYqKQQqys1IBbMAnqGsTpZN1 pPsDLlE2+LZFwiFxkkJHr7n3EOekweDF+gE/NzRu6dlf0cyMFjMzQe5DpYjcTpEK prtaXNljomyP63QS/CIqonSyhRol4fxt4Pahd9mw1OQu1LLLjB4XA7eKs6b6whRz sVwa/tyKAXl7C/QabNWWrzozo8ilZjvt0ht3HtPEIW6RQa2pmkj4lG1mm8vUnofb c7i6n94PTqzf7HNvSea9Df2hRWU4nTV05JaEyFtS1KJ6HI4p4iKJAYSogvmEZa+Q k7zQSvZVJP/nF+4wCmgZ =9MLd -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ MinGW-users mailing list [hidden email] This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:[hidden email]?subject=unsubscribe |
foo.cpp (980 bytes)
|
|
|
|
|
|
|
|
|
|
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 On 17/11/16 16:56, Anton Shepelev wrote: > Keith Marshall to Anton Shepelev: > >>> As I can tell, the variable buf is a local one, whereas >>> according to the putenv man entry, "The string pointed to by >>> string becomes part of the environment, so altering the string >>> changes the environment." >>> >>> Does the Microsoft implementation copy the string passed? >> >> Yes. Given MS-DOS' organization of the environment as a >> contiguous sequence of NUL separated name=value C strings, >> terminated by a single zero-length C string, that would have been >> a practical necessity. Of course, there's no guarantee that >> Windows' has adopted that MS-DOS environment organizational >> legacy, but the printf() statements, which I added to the sample >> implementation, confirm that the pointer returned by getenv() >> bears no relationship to the original address of the string >> passed to putenv(); > > Thanks -- that is interesing. The result would be the same if > getenv() returned a copy of the string as a safety measure. the value, immediately following the appropriate "name=" string within the environment itself. This is readily demonstrated, by adaptation of your example program (with attached setenv() implementation): #define _POSIX_C_SOURCE 200809L #include <stdio.h> #include <stdlib.h> #include <errno.h> int main( int argc, char** argv ) { char **p; const char *envval; errno = 0; setenv ("test", "1", 1); printf ( "setenv (\"test\", \"1\", 1) returned errno = %d\n", errno ); errno = 0; setenv ("test2", "2", 1); printf ( "setenv (\"test2\", \"2\", 1) returned errno = %d\n", errno ); if( (envval = getenv ("test")) != NULL ) printf ( "envval 'test' retrieved at %1$#08x; value = %1$s\n", envval ); if( (envval = getenv ("test2")) != NULL ) printf ( "envval 'test2' retrieved at %1$#08x; value = %1$s\n", envval ); for( p = _environ; *p; p++ ) printf( "%1$#08x: %1$s\n", *p ); errno = 0; unsetenv ("test"); printf ("unsetenv (\"test\") returned errno = %d\n", errno); if( (envval = getenv ("test")) != NULL ) printf ( "envval 'test' retrieved at %1$#08x; value = %1$s\n", envval ); else printf ("envval 'test' was successfully deleted\n"); return 0; } which yields output (on WinXP VM): setenv ("test", "1", 1) returned errno = 0 setenv ("test2", "2", 1) returned errno = 0 envval 'test' retrieved at 0x3d2445; value = 1 envval 'test2' retrieved at 0x3d24de; value = 2 0x3d2be0: !::=::\ 0x3d2bf0: ALLUSERSPROFILE=C:\Documents and Settings\All Users ... 0x3d32b8: WINDIR=C:\WINDOWS 0x3d32d8: _=e:/a 0x3d2440: test=1 0x3d24d8: test2=2 unsetenv ("test") returned errno = 0 envval 'test' was successfully deleted Note that the address retrieved by getenv("test") is exactly 5 bytes beyond the corresponding "test=1" string in the environment, as it is enumerated within the _environ pointer array, (so refers to the part of that string immediately following "test="). Also note that the separation of "test=1" and "test2=2" is much more than it would be, if WinXP had adopted the MS-DOS environment organization, so that assumption obviously wasn't valid, (although curiously, running the same program under wine suggests that wine has adopted exactly that organization). Further note that the setenv("test2", "2", 1) call will overwrite the stack space used by setenv("test", "1", 1), and the "test=1" string, in the environment has not been affected in any way. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJYLfz3AAoJEMCtNsY0flo/blcQAJaeLy1WILvb6lD8uKwkt7hJ eq5yZCuJxM63MvT+fsH2AYwaTpYnybSEJifJtINOaRffPcz3+m3N408aBu5aI+7g VBPKJmlniUIAhPucN1gszVoKmz6bkZd9xOQ0RmWsh9wwmQ9KuTuNbQp+xy8opiMB PAF7vT2UwsvxBK6DTblw1M25dXGdKOPPGWyFoklu4NmdiIYJNrS7zTfolD00PLSM 3NBU8LO8H1pCpyOWgVZ06ZexI1Yykxi2uESF9aOyWcNfjWO2Lm3SvK9wopjlesmX PWM1q+aFUtEn/O8tNJtIpvFMKR5rvvQPVoW/gliVlC55tOqDznkOLWbfbsgHlllj v0KuUAe2Q/wY8kL+N5yJhO9VshCgzdXbOTNNXv7Q5zxZ2H13tf6nwitAHc/31o0L MBr3q9GXCyNOe3mYAVtJks23rXYLveWrMVU9yR8L4i7hcmk+9ASZVE9LpVy370/P VuitW0ohGU871RrvJOcCq7fOlaKwGo5/nuZLHImDVm3+QPJIaIIccqeLPrT0trr0 nzU18LlIqglVPq8xCM4E8p+nYc98bAxSKy0mORnONiuE3ksTD451sv+aqEy5M4LZ a8CD35zgcg67FK8dGq/ehlSQdAaytCQWjY9BJFOkSSBWfYpth0U3W6IPIWiYPScE tdIjG2KWoyy9iHL/SAR+ =QXIP -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ MinGW-users mailing list [hidden email] This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:[hidden email]?subject=unsubscribe |
|
|
|
|
|
|
Loading...
| Free forum by Nabble | Edit this page |