Quantcast

setenv()

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

setenv()

Anton Shepelev
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]


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Eli Zaretskii
> From: Anton Shepelev <[hidden email]>
> 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.

------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Keith Marshall
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) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Anton Shepelev
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.


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Anton Shepelev
In reply to this post by Keith Marshall
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.


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Keith Marshall
In reply to this post by Anton Shepelev
-----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-----

------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Keith Marshall
In reply to this post by Anton Shepelev
-----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-----

------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Anton Shepelev
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.


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Anton Shepelev
In reply to this post by Keith Marshall
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.


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Keith Marshall
-----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-----

------------------------------------------------------------------------------

_______________________________________________
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

setenv.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Anton Shepelev
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]


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Anton Shepelev
In reply to this post by Keith Marshall
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]


------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Keith Marshall
-----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-----

------------------------------------------------------------------------------
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: setenv()

Keith Marshall
In reply to this post by Anton Shepelev
-----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-----

------------------------------------------------------------------------------
_______________________________________________
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...