Menu
▾
▴
mingw-users
|
From: Anton S. <ant...@gm...> - 2016-11-15 21:46:47
|
Hello, all
Is the setenv() function from stdlib.h supposed to
work in MinGW? When I compile the following pro-
gram:
#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
If 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);
And where is stdlib.h located? I couldn't discover
it using:
find / -name stdlib.h
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
|
|
From: Eli Z. <el...@gn...> - 2016-11-16 03:33:41
|
> From: Anton Shepelev <ant...@gm...> > Date: Wed, 16 Nov 2016 00:46:32 +0300 > > Is the setenv() function from stdlib.h supposed to > work in MinGW? The MS-Windows runtime doesn't provide setenv. Use _putenv instead. |
|
From: Keith M. <kei...@us...> - 2016-11-16 14:56:09
Attachments:
foo.cpp
|
-----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-----
|
|
From: Anton S. <ant...@gm...> - 2016-11-17 09:01:08
|
Keith Marshall: >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 simi- > lar 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. Thanks for the explanation, Keith. >Draw inspiration from the attached modification to >your original sample code, to implement setenv(), Thanks, I will. As I can tell, the variable buf is a local one, whereas according to the putenv man en- try, "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? They do not seem to mention it in the reference: https://msdn.microsoft.com/en-us/library/83zh4e6k.aspx >(or, if you raise a feature request on the issue >tracker, I may consider adding it for the next >mingwrt release). I will do it, to simplify the writing of cross-plat- form code. -- Please, do not send replies to the list to my e-mail. |
|
From: Keith M. <kei...@us...> - 2016-11-17 12:02:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/11/16 09:00, Anton Shepelev wrote: > 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." - From you reference to "man entry", may I deduce that this relates to some non-Windows implementation of putenv()? Linux' glibc perhaps? > 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(); altering that latter string, (or even just allowing it to be discarded from the stack, as in that sample implementation), after passing it to putenv() will not change the environment, (nor will it lead to environment corruption). OTOH, the temptation to strdup() the source string, before passing that to putenv(), would create a memory leak. - -- 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) iQIcBAEBAgAGBQJYLZxKAAoJEMCtNsY0flo/sOQP/iX0mh+43RjgQlWpTYg+R4Gm F7lpL9pBeNJuGgLeULGxd60k7u1yIm/li8OA1jTAeOvfzwe8nKV9YDf19lb6nI1i c8CTzTy4hGy9Ne7+8NgqszcgdHEyobUqrzDh5SeEtUWp+bCWN5RoKhu3Vrbo83C8 uYcODzbuHM/y9Qljsk095o1ZrM8sgw2vgZh8bMdnqD6ym9wnGPO0aUyRB135M0S4 m5RNSZdJbCSQq6RuYwmUaalSFyf5PCaZxB9YNJ3pEB7sOSbBXmv8GfK8Nr6zvpsO nA5yJthJM8nHjtPSFdb63crAzmXeMHftdL5xC0cpWRb5O3zeZP1fyPKw4/G4qqMG UlienocW1+IIOHmPdToBnr62gcnODyWM0AaUrONy4ukXLHCsLtkbCip2HTrF9arG QWFemEgvsD0dDu99MISKAN9qZP1frHNnKmR7TBfoMeEt85gr4i98BjHlyKwOz+UA ZJRaSYJdcY8SsCBaWCoSDP71UpqBUQS/3GfJ97dYPlbOgKe1/5Jot6Rbwe6/rGzn FMnmBMWubB3HtHxwa1tUS/BOs8DH7TrHG8kxSM0h9B2SFfsickhFXJqGUBJGxPNq n3frZyLSOAxotESfWI6fruYu8eMGDFctY2lFPqFkHXdEXMfm1ohQjYaldWSypeqc KQQpVQow2jgNs91qOl2h =SIDk -----END PGP SIGNATURE----- |
|
From: Anton S. <ant...@gm...> - 2016-11-17 11:26:36
|
Keith Marshall to Anton Shepelev: >>And where is stdlib.h located? I couldn't discov- >>er 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 rep- >resents the root of your installation tree ... >gcc.exe itself will be installed as >$MINGW_ROOT/bin/gcc.exe Ah, it is present in $MINGW_ROOT/include, but is naturally not visible from MSYS, whence I ran find. -- Please, do not send replies to the list to my e-mail. |
|
From: Keith M. <kei...@us...> - 2016-11-17 12:16:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/11/16 11:26, Anton Shepelev wrote: > Keith Marshall to Anton Shepelev: >>> 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 > > Ah, it is present in $MINGW_ROOT/include, but is naturally not > visible from MSYS, whence I ran find. In your MSYS installation, do you not have $MINGW_ROOT mounted on /mingw? Does find not traverse that mount point? (It does, for me). BTW, I've always found that "find -iname" seems to work quicker than "find -name", when running under MSYS. - -- 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) iQIcBAEBAgAGBQJYLZ94AAoJEMCtNsY0flo/qMIQAMZ1xJam1b1Iuimf3K/AfUQt U1ywJWB4RHKpgrlx1WPkKXtmUYRTQH7wJfG9oUcQZLncEZkgPgjIwHPdYIcOKwPe Vq1O3R6lbh0mBBBN+QEv0aXpuwI+/qGoLMxnHnR7hailIUcCeZoYmFl01JVshqgm 575e9Q5IVbGskZkueqNVQMQJlZ90stIzDv63tb3eTjl2dZETq+O9YQR8sEyoDnk+ bZjNTiaL7fRWZwJ0YGJ8QAYuasNAs1K0Num3SAEEZLX8KHGF2FK9uN0JmI9w8U+L M3iDSAB8exqaSEbmPMgHraE6G6HveSF1EzT712SjSki3nLjYX8oXk8/2cTHL7Osr 1GyhWb+5BcWcOY6KhFntQ3Glp4LAT8dIbefxcxTe+rFFABLIM3ZST8Mxx4Ej7RGA BnrxIonnD9rjZnvNdoEErA8371eRs0YFlw8X4cAZBiqK6H7PDNUorfnZmU2lHgem ZUpgfGT1lU0J7lZZgrgQ951GSC2C+Ps8Th8WSGrPPkT5lnum3ZRLGv3fRN5VmJib PWjG5gFmJcAie2g8SBkDdzijxXl5NxCoVh+OBMfuzoem9DzcvU5Z4c4tmxI8UFjf Dt2pE+3DjU8akzrDA2NrW2GoroexgqpKO5+sPRj52DKtaVCZn0BPFtdwE6h2vE9C LA6IuffVdWHomWxN6KS3 =KbZd -----END PGP SIGNATURE----- |
|
From: Anton S. <ant...@gm...> - 2016-11-17 15:56:21
|
Keith Marshall to Anton Shepelev: >>Ah, it is present in $MINGW_ROOT/include, but is >>naturally not visible from MSYS, whence I ran >>find. > >In your MSYS installation, do you not have >$MINGW_ROOT mounted on /mingw? Does find not tra- >verse that mount point? (It does, for me). I do, but it does not. I can cd to /mingw, but ls will not list it even with -a. Consequently, it is invisible to find. >BTW, I've always found that "find -iname" seems to >work quicker than "find -name", when running under >MSYS. Thanks. -- Please, do not send replies to the list to my e-mail. |
|
From: Anton S. <ant...@gm...> - 2016-11-17 16:56:27
|
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." > >- From you reference to "man entry", may I deduce >that this relates to some non-Windows implementa- >tion of putenv()? Linux' glibc perhaps? Yes, it is glibc. >>Does the Microsoft implementation copy the string >>passed? > >Yes. Given MS-DOS' organization of the environment >as a contiguous sequence of NUL separated name=val- >ue 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. -- Please, do not send replies to the list to my e-mail. |
|
From: Keith M. <kei...@us...> - 2016-11-17 18:54:55
Attachments:
setenv.patch
|
-----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.
True, but it doesn't work that way -- getenv() returns a pointer to
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-----
|
|
From: Anton S. <ant...@gm...> - 2016-11-19 10:05:35
|
Keith Marshall:
> Anton Shepelev:
> > Keith Marshall:
> >
> > > 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 sam-
> > > ple implementation, confirm that the pointer
> > > returned by getenv() bears no relationship to
> > > the original address of the string passed to
> > > putenv(); altering that latter string, (or
> > > even just allowing it to be discarded from the
> > > stack, as in that sample implementation), af-
> > > ter passing it to putenv() will not change the
> > > environment, (nor will it lead to environment
> > > corruption). OTOH, the temptation to strdup()
> > > the source string, before passing that to
> > > putenv(), would create a memory leak.
> >
> > The result would be the same if getenv() re-
> > turned a copy of the string as a safety measure.
>
> True, but it doesn't work that way -- getenv() re-
> turns a pointer to the value, immediately follow-
> ing the appropriate "name=" string within the en-
> vironment itself. This is readily demonstrated,
> by adaptation of your example program (with at-
> tached setenv() implementation):
Thanks for the patch!
> #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 enu-
> merated within the _environ pointer array, (so
> refers to the part of that string immediately fol-
> lowing "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 pro-
> gram under wine suggests that wine has adopted ex-
> actly 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.
Understood.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
|
|
From: Keith M. <kei...@us...> - 2016-11-28 14:30:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/16 10:05, Anton Shepelev wrote: > Thanks for the patch! You're welcome. I committed it, as: https://sourceforge.net/p/mingw/mingw-org-wsl/ci/baddeff0bb85a2054392eb93292f21436d8db1f4/ - -- 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) iQIcBAEBAgAGBQJYPD+IAAoJEMCtNsY0flo/RxMP/RzDspvw2DzdPnEuz301Nfuz tpnv7qc+L2iUYHR5D+yyZhOlUK4bxh6AJlFoRnOEPSRtyyKapwLbeuPe2Af6Rf2D oTdTvEVJvfOS/CEzor01nNLkhD5XDJvftQ2mAnTRd8lLudkIDioP7cHyvpI8gJi2 bSLfzz6hqYRz6sXQa+3eiKo2ZA3GbNySC4Yez8Wo5noQn0PrlupIXC/dTA7q+WqO EO4LBJQRP5pXRVmPBOkK7tTYeBjpzKTiHkjlcEOVQ9GSEfZGZcGEOE4+cHCKT2Dl o4LWlWSRV6WOpgjHbLO+s8J7n9X2HVteN6xx7T4A9cnKno0fQHDf8+5xb0KlaVCR NgxR+9paB+2FlImptjADbVqP2g9n+k0Jns+nyXo9eldvVR4rATMvx1UcmuRTPJym 2fKcwBN08xI5uzL3gjVk1IAbxfFIMmzMbjwaYwDzEWpg10DnijT9uv8dBJJG9DOW BGE85YmfR1xc9lSxAq+tl0ItHnib36EildbG0o3nqoK02WOZtn1W2QFfPzy5ACN6 B7oK4EHR0dfDoPU6M+uMBUk+6TyD9JjQY3FQgXPUgoHl1SqgIJ1zeJDx+RELYUY4 vf16cWADL7i5jHC+xTvewtwbzB2sJEpSXOL8Ytzlv94NFfLanQrkhQtIqD6xPjky aLIUE5oPhSQLnk3skDzK =fGLj -----END PGP SIGNATURE----- |
|
From: Anton S. <ant...@gm...> - 2016-11-19 10:10:18
|
Keith Marshall: > 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). Issue created: https://sourceforge.net/p/mingw/bugs/2319/ -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
|
From: Keith M. <kei...@us...> - 2016-11-19 22:53:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/11/16 10:07, Anton Shepelev wrote: > Keith Marshall: > >> 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). > > Issue created: > > https://sourceforge.net/p/mingw/bugs/2319/ Thanks, Anton. I added a proposed implementation patch to that ticket. - -- 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) iQIcBAEBAgAGBQJYMNfTAAoJEMCtNsY0flo/KUcQALF38uF5PrujwurpvLIJbXHW aiGAsS8ZAUXiYGaalrrM2qgqSiMKJQLe9DY01s0OcLcj3vgZ2g8UENLzpymyXPJv ugEb+EZTkMDacbSOpkCGwwUPvPB8QHtkAxCsG3pnnTQPVSXdmdfx5j5MiZEv3Tsk A1ubY1cwC7QhHQNEOxq6Qqk7nfmtkncgokb7bkD7xkopCI1CzXM5uvIed8AKmXyG r3emwpUJDwgJZQhAvCuvAIqhbiMy8Ry1dB5cf574KZ+GjrqoVou2jZTqsTZA3raA icy8jUEBDzR/8Mpps8XhLeEM6PxAXnToiPgcQFx1lOGK6k+FDLIzba7JmPCxuk1g e1Kb5jQENDWQZOTmlblxXnqXl3DzPHiOj+tskDJRcvboF4pb6Nn+oGiVWXIkzPWl lLJuMPCSKsRmSp+euxB9av05dRfNfvkBuCjbLrIQWZEWFxvnzkrI+n5b2yeKKLGW iyos0RGbj7qnceeXZsmQba/0IJu/IvaH6VmPYmBc/rTPx5ueUsCKrhVukfRYRqqA dow9thFxH1vco9c0SKhjstTa0B0pJffJ5Fdh3lPsdLFT/uy4ehQOaBKKJGLfVgKW rn6QEOdbcSitOLXCfJBPcZKTbUpCHlO5DbnOPpU/xD3mJ2oBvUNRXJ2BcJbPvLPF gmR9m7+QREUf+dwv3PCU =+Bmb -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X