Что происходит с памятью, когда мы используем putenv() для переменной окружения, которая уже существует?

Жалко, что вы переработали свой вопрос из первой версии, которая касалась setenv(), потому чтоsetenv()имеет утечку памяти, по крайней мере, в реализации glibc.

Возьмите этот пример программы; он будет расти и расти, пока не съест всю память, которую сможет:

#include <stdlib.h>
#include <stdio.h>
int main(void){
        char buf[24];
        for(;;){
                snprintf(buf, sizeof buf, "%d", rand());
                setenv("foo", buf, 1);
        }
}

В реализации glibc setenv()никогда не будет освобождаться память, уже выделенная предыдущим setenv(); однако он будет избегать дублирования, отслеживая строки среды, выделенные им в двоичном дереве (с использованием tfind(3), отдельно от списка char **environ). Это также дает хороший эффект сокрытия утечки от таких инструментов, как valgrind;-)

Что касается putenv(), он полагается на то, что вызывающий объект управляет строкой, переданной ему в качестве аргумента. Таким образом, задача вызывающей стороны состоит в том, чтобы убедиться, что она не пропустит его при повторном вызове putenv(), что он не освободит его, пока он все еще является частью среды, и что он не использует для этого автоматическую/стековую переменную.

Кроме того, изменение строки после вызова putenv()может привести к удалению переменной среды или добавлению другой. Пример:

#define _XOPEN_SOURCE   500
#include <stdlib.h>
#include <stdio.h>
#include <err.h>
#include <unistd.h>
int main(void){
        extern char **environ;
        static char *my_environ[] = { "YUCK=yumm", 0 };
        static char str[256] = "FOO=bar";
        environ = my_environ;
        putenv(str);
        snprintf(str, sizeof str, "BAZ=quux");
        execl("/usr/bin/printenv", "printenv", (void*)0);
        err(1, "execlp");
}

Это требуется по стандарту, но не работало в старых версиях glibc, где putenv()делал копию своего аргумента.

Наконец, и setenv(), и putenv()будут перемещать массив char **environпри добавлении новой переменной в среду.Реализация сохранит свою собственную копию указателя и увеличит ее с помощью realloc(), но не будет возиться со своим исходным (, который указывает на статическую память ), или с памятью, выделенной вручную, например. environ = calloc(sizeof *environ, envlen).

Окружающая среда состоит из трех вещей.

1. Двойной указатель, скажем, envp, называемый environment list pointer.

2. Это указывает на environment list, который вы можете представить как массив указателей, указывающих на строки окружения.

3. environment strings, которые имеют форму name=value.

Теперь, где это хранится в макете виртуальной машины процесса?

Ответ: -над стеком; мы можем назвать его старшим адресом .

Он имеет бетонный потолок и бетонное дно ; так как выше нельзя расширить, потому что это потолок планировки; ниже вы не можете расширяться из-за наличия стека.

Теперь о вашем вопросе.--

Когда вы изменяете строку на любое значение, превышающее длину, которую может вместить верхний сегмент, она внутренне, по существу, выполняет malloc.

Затем указатель в списке сред изменяется, чтобы указывать на эту распределенную память. Итак, у вас будет список окружения, в котором некоторые указатели по-прежнему указывают на адреса в верхней памяти, в то время как этот конкретный указатель будет указывать на область в куче . В этом конкретном случае модификации параметра весь список окружения не копируется в кучу.

Что происходит с предыдущей памятью, на которую указывал указатель? Что ж, это выглядит как утечка памяти, но обычно утечкой не является.поскольку эта память уже была там и теперь является бесполезным куском, на который больше нельзя указать.

Я бы не назвал это утечкой памяти, потому что это было не динамическое выделение, а статическое, которое уже было; часть зарезервированного сегмента.

Утечка памяти звучит как некоторая часть памяти, которую вы могли бы использовать для чего-то другого, но не можете, так как нет способа добраться до нее. Но этот кусок памяти по старшему адресу в любом случае был недоступен вам ни для чего другого.

Итак, похоже на утечку памяти; но я бы не назвал это типично так!

Извините за путаницу, я старался быть как можно более ясным:)