🚀 go-pugleaf

I've figured out HOW the problem occurs, i just dont know WHY it occurs, or
WHY it should occur. Possibly a bug in the c libs or gcc??
The HOW is: when you putenv() an array, and then modify the array afterwards,
the environment automatically gets changed without executing another
putenv()! This, to me, sounds ludicrous. Even setting the array below to
static char doesn't help.
Sample program:

#include <stdio.h>
#include <unistd.h>

int main(void) {
char timebuf[256];

strcpy(timebuf,"TZ=:/home/flirt/ncohafmuta/tzinfo/US/Central");
printf("Setting TZ to: %s\n",timebuf);
putenv(timebuf);
tzset();
printf("TZ is: %s\n",(char *)getenv("TZ"));
strcpy(timebuf,"TZ=hi");
printf("Redefined timebuf to: %s\n",timebuf);
printf("TZ is: %s\n",(char *)getenv("TZ"));
return 1;
}



-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                       Network Administrator/Engineer
admin@intergrafix.net                    Intergrafix Internet Services

    "Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com                http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

In comp.unix.programmer admin@intergrafix.net wrote:
> Hi,

> I write this chat program in C. The platform is linux. The libraries are
> libc 5.4.46-2 and glibc 2.1.3-6, on 2 different machines.

> At the start of the program i have code to set the timezone up to whatever is
> specified in a #define called TZONE, such as "US/Pacific"

> the function i made to accomplish this is:

> void do_timeset(void) {
> char wcd1[266];

> getcwd(wcd1,256);
> /* subdirectory under the absolute cwd where zonefiles are kept */
> /* we dont use the machines own zoneinfo files */
> strcat(wcd1,"/tzinfo");
> sprintf(mess,"TZ=:%s/%s",wcd1,TZONE);
> putenv(mess);
> tzset();
> }

> this works fine. when i do a time(&tm); and then output a ctime(&tm);
> it prints out the current time for the zone.

> however, after a few lines of simple code, and then printing out the time
> again, it reverts back to local machine time! but only on glibc, on the libc5
> it still prints out the right time for the zone.
> after checking the environment, i've noticed that after a line of code, the 
> TZ variable just disappears! it disppearrs on both the libc5 and the glibc,
> but only the glibc makes it take effect as previously stated.

> why the TZ varaible gets lost, i have no clue. it doesn't matter what the
> code line is that makes it get lost either..for example..if i have the code:

> do_timeset();
> system("env");
> time(&tm);
> printf("%s",ctime(&tm));
> mess[0]=0;
> system("env");
> time(&tm);
> printf("%s",ctime(&tm));
> somevariable=1;
> system("env");
> time(&tm);
> printf("%s",ctime(&tm));

> the first env will be correct, the second and third ctime() will be missing
> the TZ. if i comment out the mess[0]=0; then the first and second ctime()
> will be right and the third ctime will be wrong (as a result of the code
> somevariable=1;) btw, mess is a global char of size 9600
> if i redo the do_timeset() after all that, it will come back to the current
> time, but then on the very next line of code it will revert.

> i've written a small sample problem and could not get the problem to
> reproduce there. so i assume it's something in my programming, i'd just like
> to know what the heck I could be coding wrongly that would cause this
> to happen! :( Or even what concepts would cause this to happen.

> lastly i'd like to add, relevantly maybe, that i'm not doing anything like
> forking, or any kind of system calls besides the debugging ones listed above.

> Any help would be appriecated,

> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco                       Network Administrator/Engineer
> admin@intergrafix.net                    Intergrafix Internet Services

>     "Dream as if you'll live forever, live as if you'll die today"
> http://cygnus.ncohafmuta.com                http://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.


.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco                       Network Administrator/Engineer
admin@intergrafix.net                    Intergrafix Internet Services

    "Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com                http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

>>>>> "Tony" == admin  <admin@intergrafix.net> writes:

Tony> I've figured out HOW the problem occurs, i just dont know WHY
Tony> it occurs, or WHY it should occur. Possibly a bug in the c libs
Tony> or gcc??  The HOW is: when you putenv() an array, and then
Tony> modify the array afterwards, the environment automatically gets
Tony> changed without executing another putenv()! This, to me, sounds
Tony> ludicrous. Even setting the array below to static char doesn't
Tony> help.

That's the expected behavior of putenv().

From the man page for putenv:

   The memory space pointed to by the String parameter becomes part of
   the environment, so that altering the string effectively changes part
   of the environment.

-bill

admin@intergrafix.net writes:

> I've figured out HOW the problem occurs, i just dont know WHY it occurs, or
> WHY it should occur. Possibly a bug in the c libs or gcc??
> The HOW is: when you putenv() an array, and then modify the array afterwards,
> the environment automatically gets changed without executing another
> putenv()! This, to me, sounds ludicrous. Even setting the array below to
> static char doesn't help.

Believe it or not, this is correct behavior.  According to the Single
Unix Spec
(http://www.opengroup.org/onlinepubs/7908799/xsh/putenv.html):

# The putenv() function makes the value of the environment variable
# name equal to value by altering an existing variable or creating a
# new one. In either case, the string pointed to by string becomes
# part of the environment, so altering the string will change the
# environment. The space used by string is no longer used once a new
# string-defining name is passed to putenv().

If you want it to be independent, use strdup or something of the sort.

A note to this effect appears to have been added to the glibc
documentation recently; it may not be in your version.

-- 

Nate Eldredge
neldredge@hmc.edu