39
 char * val;                                                                        
 val = getenv("ENV_VAR_NAME");

above is a code to get environment variable, will it cause memory leak if I dont free memory returned by getenv(char*) ? If no then please answer why?

user5534993
  • 518
  • 2
  • 17
SunnyShah
  • 28,934
  • 30
  • 90
  • 137

5 Answers5

45

No you shouldn't. Standard 7.20.4.5 says :

The getenv function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to the getenv function.

I believe deletion is covered by the text in bold.

icecrime
  • 74,451
  • 13
  • 99
  • 111
  • Yes, in practice, if I call char * tok = strtok() with its first parameter be return of getenv(). The strlen(tok) and puts(tok) won't work... A quite wired result. I think it was caused by strtok() is covered by the text in bold. – ackratos Jul 01 '15 at 12:38
  • 1
    A bit out of date but the linux man pages say `char* getenv()` and not `const char* getenv()`. I discovered this since my machine wasn't to happy about me freeing the string. Are the man pages not completely correct? I was allways under the impression when a fuction returns a `char*` one should free it.? – hetepeperfan Jan 12 '17 at 09:26
  • @hetepeperfan It's not just the man page. The function prototype for `getenv` indeed returns `char *` and not `const char *`. Maybe the interface predates common usage of `const`, or maybe it's just an oversight that went unaddressed for too long. Agreed that it is misleading. – jdolan Dec 31 '17 at 16:10
14

You should not free it. This is a snippet from the man page:

As typically implemented, getenv() returns a pointer to a string within the environment list. The caller must take care not to modify this string, since that would change the environment of the process.

Don't touch it !

Matt Joiner
  • 112,946
  • 110
  • 377
  • 526
Nicolas Viennot
  • 3,921
  • 1
  • 21
  • 22
9

No. You don't control its storage. Typically, it's a pointer to a static array that is reused multiple times. For this reason, you should copy it if you plan to store it for later use (you should ensure this copy is freed properly).

Unless the documentation explicitly says you may free a pointer, you should not.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • 1
    I'm not sure about in general, but on POSIX systems there is no use in storing the string unless your program modifies the environment. The pointer returned points directly to the internal copy, not a temporary buffer. – R.. GitHub STOP HELPING ICE Nov 21 '10 at 12:46
  • @R, it the docs [say](http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html) "The return value from getenv() may point to static data which may be overwritten by subsequent calls to getenv() [...]". So it can change even if there are no `putenv` calls. – Matthew Flaschen Nov 21 '10 at 12:58
  • That language has been deleted in Issue 7, but it still claims the function is not thread-safe. I suppose the only strictly sanctioned thread-safe way to access the environment is via `extern char **environ;`... – R.. GitHub STOP HELPING ICE Nov 21 '10 at 13:48
  • @R, thanks, I didn't realize that wasn't the latest version. But it was only removed from the return value section. The description still reads, "The string pointed to may be overwritten by a subsequent call to getenv() [...]". I don't think modifying `environ` is the solution, since it says, "Conforming applications are required not to modify environ directly." I'm not sure why there's still no `getenv_r` call. – Matthew Flaschen Nov 21 '10 at 14:04
5

You shouldn't delete it. Getenv just get a value from a char* array (char** environ, if I remember correctly), that contains every environment variable. Deleting them causes undefined behaviour.

Raveline
  • 2,660
  • 1
  • 24
  • 28
2

Probably the best reason why is that the standard does not say you can. Just because a function returns a pointer does not mean that pointer is valid to pass to free. Unless the documentation of a function says specifically that the function allocates memory "as if by calling malloc" and returns a pointer to that memory, you must assume the pointer is not valid to pass to realloc or free.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711