@cmb69 reported on the mailing list that Windows environment variables set via SetEnvironmentVariable are visible to GetEnvironmentVariable but not to getenv. I've confirmed this.

Some builds of Windows php for their own API putenv call SetEnvironmentVariable instead of putenv. That can lead to a bug. In that case a user set some PROXY variables via php's putenv and when curl retrieved them via getenv they were not found. (Christoph please correct this if I misinterpreted)

Related issues

cmb69's e-mail also points out getenv is not thread safe but I assume he means if the environment block is modified. This is a well known issue for various runtimes and perhaps we should warn about using putenv in the thread safety guidelines.

The curl tool's GetEnv already uses GetEnvironmentVariable instead of getenv and there is a comment "Don't use getenv(); it doesn't find variable added after program was started". Frankly that doesn't make a lot of sense, and as far as I can tell is not true (set a variable with putenv and it's immediately avaiable via getenv). It's possible the author was mistaken and had the same issue discussed here.

Remedy

To completely remedy this in curl would require a bit of work since we call getenv multiple places without having to worry about memory management, like we would with curl_getenv. We could at least address the php bug by improving on curl_getenv to obtain variables via GetEnvironmentVariable instead of getenv. The easiest way to do that is c&p of GetEnv from the tool and use it in the lib:

diff --git a/lib/getenv.c b/lib/getenv.c
index e444a6a..9ca8f19 100644
--- a/lib/getenv.c
+++ b/lib/getenv.c
@@ -34,17 +34,31 @@ char *GetEnv(const char *variable)
   (void)variable;
   return NULL;
 #else
+  char *env = NULL;
 #ifdef WIN32
-  char env[4096];
-  char *temp = getenv(variable);
-  env[0] = '\0';
-  if(temp != NULL)
-    ExpandEnvironmentStringsA(temp, env, sizeof(env));
-  return (env[0] != '\0')?strdup(env):NULL;
+  char  buf1[1024], buf2[1024];
+  DWORD rc;
+
+  /* Don't use getenv(); it doesn't find variable added after program was
+   * started. Don't accept truncated results (i.e. rc >= sizeof(buf1)).  */
+
+  rc = GetEnvironmentVariableA(variable, buf1, sizeof(buf1));
+  if(rc > 0 && rc < sizeof(buf1)) {
+    env = buf1;
+    variable = buf1;
+  }
+  if(strchr(variable, '%')) {
+    /* buf2 == variable if not expanded */
+    rc = ExpandEnvironmentStringsA(variable, buf2, sizeof(buf2));
+    if(rc > 0 && rc < sizeof(buf2) &&
+       !strchr(buf2, '%'))    /* no vars still unexpanded */
+      env = buf2;
+  }
 #else
-  char *env = getenv(variable);
-  return (env && env[0])?strdup(env):NULL;
+  /* no length control */
+  env = getenv(variable);
 #endif
+  return (env && env[0]) ? strdup(env) : NULL;
 #endif
 }

Is there an acceptable way to deduplicate functions used by both the tool and lib? I know of curlx but I understand those are deprecated, therefore if I wanted change GetEnv in the tool to call curlx_getenv (which would then call GetEnv in the lib and now has the same code) would that be acceptable?

To address this fully would require banning getenv and then replacing it with curl_getenv everywhere, and I think that's unnecessary. I'd rather note KNOWN_BUGS there may be circumstances where curl may not recognize variables set via SetEnvironmentVariable.

curl/libcurl version

curl 7.68.0-DEV (i386-pc-win32) libcurl/7.68.0-DEV