Conference turris::decc

    The function putenv() is new to OpenVMS V7.0.  Attempts to use this
    function on a version of OpenVMS prior to V7.0 will result in an
    undefined global decc$putenv (assuming /prefix=all).
    
    With DEC C V5.6, an object library DECC$CRTL.OLB is placed into
    SYS$LIBRARY along with instructions DECC$CRTL.README which detail how
    to use this object library.  
    
    Linking your application with the DECC$PUTENV resolved from this new
    object library should work.  Are you saying that you are getting
    undefined globals or that the one in the object library fails to work?
    
    Duane

:    the chapter "Version Dependancy Tables" says that the function "putenv"
:    is added in OpenVMS V7.0
:
:    Today, with DECC V5.6, is it always true that putenv doesn't work with
:    OpenVMS Alpha V6.1 or V6.2 ?

   RTL functions are tied to the OpenVMS release -- the RTL shareables
   ship with OpenVMS, not with the compiler.

   If you need the putenv call prior to OpenVMS V7.0 (and you don't
   want to link against the latest DEC C object library), please use
   the lib$set_symbol or the lib$set_logical routines from the RTL.

    Duan,

    Thank you for your quick reply.

    The environment is OpenVMS Alpha V6.2, DECC V5.6
    The problem is that getenv always returns a null string.

    	$ define decc$crtlmap sys$library:decc$crtl.exe
    	$ define lnk$library  sys$library:decc$crtl.olb

    	$ cc/stand=vaxc	      putenv.c
    	$ link		      putenv

    	$ cc/stand=vaxc	      getenv.c
    	$ link		      getenv

    	$ run		      putenv
    	status = 0

    	$ run getenv
    	TESTTCP = (null)

    Regards.
    Cheu.

    --------------------------------------------------------------------------
    /* putenv.c */
    #include <stdlib.h>

    main ()
    {
      int status;

      status = putenv("TESTTCP=abcdef");
      printf ("status = %d\n", status);
    }

    --------------------------------------------------------------------------
    /* getenv.c */

    #include <stdlib>

    main ()
    {
        printf ("TESTTCP = %s\n", getenv("TESTTCP"));
    }
    

    Steve,

    	Thank you for the alternatives solutions.

    Regards.
    Cheu.

    I don't want to burst any bubbles, but changes made via putenv() are
    only visible to getenv() calls within that image activation.  The
    equivalences given to putenv() are not saved in the state as logical
    names or symbols.
    
    You may want to write a private putenv() which does as suggested in .2
    
    Duane

RE .5:

> changes made via putenv() are only visible to getenv() calls within
> that image activation.

In the typical case, a VMS image activation corresponds to a process
creation on UNIX.  A UNIX shell forks before exec-ing a program.
So each successive program invoked at the command line runs in
a different process.  And like the above-cited property of the
effect of a putenv being visible only within the same image activation
on VMS, a putenv on UNIX only affects the current process.  So if you
run a UNIX program that does a putenv, and then run a program that
does a getenv, you will not see its effect since the new program
will run in a new process, inheriting only the environment variables
of the parent shell process.

While debugging a problem in 'dop' (a system utility that allows normal users to
run superuser programs), I discovered that changing the contents of the string
in your program can actually change the program's environment. Note that this
feature was the cause of a now famous security bug in Digital UNIX V4.0 that
takes advantage of this bug in the dop source code.

Below is an example of how it works on Digital UNIX, taken from OSF_QAR 50146,
which I reported against the putenv(3) man page:

 The putenv(3) man page does not specify that changing the string
 will change the environment. Although this behavior is similar to
 that of other UNIX implementations, this is a subtle point that
 needs to be described.

 The man page may lead one to believe that a copy of the string is
 stored in the environ after the putenv call, when it actually just
 stores a pointer to the original string. Changing the original string
 contents will therefore change the environment.

 Below is a simple program that demonstrates that case:

 % cat putenv_test.c

 #include <stdlib.h>
 #include <stdio.h>

 void print_env(char *);

 main() {
   char tmpstring[20];

   print_env("HOME set by default, TEMPENV not set:");

   strcpy(tmpstring, "HOME=/usr/newhome");
   putenv(tmpstring);
   print_env("Reset HOME, TEMPENV not set:");

   strcpy(tmpstring, "TEMPENV=tempenv");
   putenv(tmpstring);
   print_env("Set TEMPENV:");

   /*
    * Surprise!
    */
   strcpy(tmpstring, "HOME=OOPS putenv() not called!");
   print_env("No putenv called:");

 }

 void print_env(char *str) {
   char *envptr;

   printf("\n%s\n", str);

   envptr = getenv("HOME");
   if (envptr)
     printf("HOME=%s\n", envptr);
   else
     printf("HOME not set\n");

   envptr = getenv("TEMPENV");
   if (envptr) 
     printf("TEMPENV=%s\n", envptr);
   else
     printf("TEMPENV not set\n");
 }

 % cc putenv_test.c; a.out

 HOME set by default, TEMPENV not set:
 HOME=/home/jps
 TEMPENV not set

 Reset HOME, TEMPENV not set:
 HOME=/usr/newhome
 TEMPENV not set

 Set TEMPENV:
 HOME not set
 TEMPENV=tempenv

 No putenv called:
 HOME=OOPS putenv() not called!
 TEMPENV not set


 This misunderstanding was the cause of a problem reported
 against /usr/sbin/dop today by me.


The dop qar was OSF_QAR 50148.


-Jeff

And an infamous contractor hired to port Netscape to OpenVMS could not 
understand why the first call failed, and the next call worked.  

a getenv then a strcpy into the result..  

"it should not do that"

I think it took three Digital engineers (two of which worked on the CRTL) to
tell him that it was not legal to do that.


A little over a year ago his contract was not extended and his changes 
began to be removed.

bjm