getenv, putenv - Linux

This is a discussion on getenv, putenv - Linux ; Hi, I am running a multithreaded application in which I am trying to set an environment variable using putenv. The string I am using as argument to putenv was created as char *str=strdup( ); When I try to invoke same ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: getenv, putenv

  1. getenv, putenv

    Hi,

    I am running a multithreaded application in which I am trying to set
    an environment variable using putenv. The string I am using as
    argument to putenv was created as

    char *str=strdup();

    When I try to invoke same environment variable using another thread
    within same process using getenv, I am not able to access the value of
    env variable.

    Can Anyone please let me know, what could be the probable reason for
    this problem.

    Thanks and Regards
    Bhawna

  2. Re: getenv, putenv

    > When I try to invoke same environment variable using another thread
    > within same process using getenv, I am not able to access the value of
    > env variable.
    >
    > Can Anyone please let me know, what could be the probable reason for
    > this problem.


    AFAIR there was some spec that said that you can't use getenv to
    retrieve variables set by the same process. setenv is just there to
    pass
    variables to child processes.

    I also run into this a few years ago and it has nothing to do with
    multithreading.
    If you can use setenv/getenv in the same process it is an
    implementation
    detail but trust it - and by the way why do you want to do it anyway.

  3. Re: getenv, putenv

    Bhawna wrote:
    >Hi,
    >
    >I am running a multithreaded application in which I am trying to set
    >an environment variable using putenv. The string I am using as
    >argument to putenv was created as
    >
    >char *str=strdup();


    1) Don't use an auto variable.
    2) The symbol "str" violates the implemenation's
    name space if you have also included .


    static char *my_env_var;

    void foo(void)
    {
    char local_var[BUFSIZ];

    ... /* code that sets localvar to some specific value */
    my_env_var = strdup(local_var);
    putevn(my_env_var);
    }

    >When I try to invoke same environment variable using another thread
    >within same process using getenv, I am not able to access the value of
    >env variable.
    >
    >Can Anyone please let me know, what could be the probable reason for
    >this problem.


    From the GNU man page:

    The libc4 and libc5 and glibc 2.1.2 versions conform
    to SUSv2: the pointer string given to putenv() is
    used. In particular, this string becomes part of the
    environment; changing it later will change the
    environment. (Thus, it is an error is to call
    putenv() with an automatic variable as the argument,
    then return from the calling function while string is
    still part of the environment.)

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  4. Re: getenv, putenv

    floyd@apaflo.com (Floyd L. Davidson) writes:
    > Bhawna wrote:
    >>Hi,
    >>
    >>I am running a multithreaded application in which I am trying to set
    >>an environment variable using putenv. The string I am using as
    >>argument to putenv was created as
    >>
    >>char *str=strdup();

    >
    > 1) Don't use an auto variable.


    This doesn't matter. The string needs to be alive for as it is still
    part of the environment, not some random pointer to it.

    > 2) The symbol "str" violates the implemenation's
    > name space if you have also included .


    I don't think so. SUS only reserves any identifier beginning with str,
    followed by a lower case letter.

  5. Re: getenv, putenv

    Rainer Weikusat writes:

    > floyd@apaflo.com (Floyd L. Davidson) writes:
    >> Bhawna wrote:
    >>>Hi,
    >>>
    >>>I am running a multithreaded application in which I am trying to set
    >>>an environment variable using putenv. The string I am using as
    >>>argument to putenv was created as
    >>>
    >>>char *str=strdup();

    >>
    >> 1) Don't use an auto variable.

    >
    > This doesn't matter. The string needs to be alive for as it is still
    > part of the environment, not some random pointer to it.
    >
    >> 2) The symbol "str" violates the implemenation's
    >> name space if you have also included .


    You mean string.h.

    > I don't think so. SUS only reserves any identifier beginning with str,
    > followed by a lower case letter.


    Correct, and the reservation only applies to identifiers with file
    scope, so an identifier with block scope can safely be called 'str'.

    --
    Måns Rullgård
    mans@mansr.com

  6. Re: getenv, putenv

    Rainer Weikusat wrote:
    >floyd@apaflo.com (Floyd L. Davidson) writes:
    >> Bhawna wrote:
    >>>Hi,
    >>>
    >>>I am running a multithreaded application in which I am trying to set
    >>>an environment variable using putenv. The string I am using as
    >>>argument to putenv was created as
    >>>
    >>>char *str=strdup();

    >>
    >> 1) Don't use an auto variable.

    >
    >This doesn't matter. The string needs to be alive for as it is still
    >part of the environment, not some random pointer to it.


    In particular, this string becomes part of the
    environment; changing it later will change the
    environment. (Thus, it is an error is to call
    putenv() with an automatic variable as the
    argument, then return from the calling function
    while string is still part of the environment.)

    That, once again, is directly from the man page for
    the GNU putenv(3). The string may well be alive, but
    that random pointer to it is what is part of the
    environment, and it will not be valid.

    --
    Floyd L. Davidson
    Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

  7. Re: getenv, putenv

    floyd@apaflo.com (Floyd L. Davidson) writes:

    > Rainer Weikusat wrote:
    >>floyd@apaflo.com (Floyd L. Davidson) writes:
    >>> Bhawna wrote:
    >>>>Hi,
    >>>>
    >>>>I am running a multithreaded application in which I am trying to set
    >>>>an environment variable using putenv. The string I am using as
    >>>>argument to putenv was created as
    >>>>
    >>>>char *str=strdup();
    >>>
    >>> 1) Don't use an auto variable.

    >>
    >>This doesn't matter. The string needs to be alive for as it is still
    >>part of the environment, not some random pointer to it.

    >
    > In particular, this string becomes part of the
    > environment; changing it later will change the
    > environment. (Thus, it is an error is to call
    > putenv() with an automatic variable as the
    > argument, then return from the calling function
    > while string is still part of the environment.)
    >
    > That, once again, is directly from the man page for
    > the GNU putenv(3). The string may well be alive, but
    > that random pointer to it is what is part of the
    > environment, and it will not be valid.


    Sorry, but you're wrong this time. The pointer *value* remains valid
    even after the pointer *variable* goes out of scope. Passing the
    address of a local variable to a function that stored it for later use
    would be wrong, but that's not happening here.

    --
    Måns Rullgård
    mans@mansr.com

  8. Re: getenv, putenv

    On Jan 30, 8:59 pm, llothar wrote:
    > > When I try to invoke same environment variable using another thread
    > > within same process using getenv, I am not able to access the value of
    > > env variable.

    >
    > > Can Anyone please let me know, what could be the probable reason for
    > > this problem.

    >
    > AFAIR there was some spec that said that you can't use getenv to
    > retrieve variables set by the same process. setenv is just there to
    > pass
    > variables to child processes.
    >
    > I also run into this a few years ago and it has nothing to do with
    > multithreading.
    > If you can use setenv/getenv in the same process it is an
    > implementation
    > detail but trust it - and by the way why do you want to do it anyway.


    The reason for it is as I posted as another message. Please find
    details below.

    We are using a multithreaded application which has a few dynamic
    shared objects associated with it. We are running it on Linux
    platform. Few of the classes and code part is common among main
    executable and other DSOs. The DSOs have been linked using linker
    option -Bsymbolic and so are able to keep their seperate objects for
    common classes.

    The issue we are having is we want to keep a true singleton of the
    common class without disturbing current linker option. For this
    purpose, we are allocating a new TLS key and putting this key into
    environment, so that once initialised same object is used among all
    DSOs. Based on what I read in man pages of pthread_key_create,
    pthread_setspecific and pthread_getspecific, I can create a key as an
    opaque object among multiple threads, but the values will still be
    thread specific.

    My specific questions in this scenario is:
    1. Can I use TLS key-value pair common among multiple threads of an
    application? If yes, can anybody please provide me any link to help me
    on this?
    2. Is there any other approach I can use to ensure that I have a
    common object being shared among multiple threads belonging to
    different DSOs, inspite of using -Bsymbolic linker option with DSOs?
    3. Or is there any way to override the effect of -Bsymbolic linker
    option for some specific symbols in any DSO, so as to ensure existence
    of common symbols.

    Any help in this regard willl be greatly appreciated.

    Thanks and Regards
    Bhawna

  9. Re: getenv, putenv

    floyd@apaflo.com (Floyd L. Davidson) writes:
    > Rainer Weikusat wrote:
    >>floyd@apaflo.com (Floyd L. Davidson) writes:
    >>> Bhawna wrote:
    >>>>Hi,
    >>>>
    >>>>I am running a multithreaded application in which I am trying to set
    >>>>an environment variable using putenv. The string I am using as
    >>>>argument to putenv was created as
    >>>>
    >>>>char *str=strdup();
    >>>
    >>> 1) Don't use an auto variable.

    >>
    >>This doesn't matter. The string needs to be alive for as it is still
    >>part of the environment, not some random pointer to it.

    >
    > In particular, this string becomes part of the
    > environment; changing it later will change the
    > environment. (Thus, it is an error is to call
    > putenv() with an automatic variable as the
    > argument, then return from the calling function
    > while string is still part of the environment.)
    >
    > That, once again, is directly from the man page for
    > the GNU putenv(3). The string may well be alive, but
    > that random pointer to it is what is part of the
    > environment, and it will not be valid.


    To maybe add some clarification here: The 'automatic variable' above
    refers to an array of characters with automatic storage duration, not
    to a pointer to an array of characters.

+ Reply to Thread