glibc/stdlib/tst-environ-change-3.c

#define DO_EARLY_SETENV 1
#define DO_MALLOC 0
#include "tst-environ-change-skeleton.c"
stdlib: Re-implement free (environ) compatibility kludge for setenv For the originally failing application (userhelper from usermode), it is not actually necessary to call realloc on the environ pointer. Yes, there will be a memory leak because the application assigns a heap-allocated pointer to environ that it never frees, but this leak was always there: the old realloc-based setenv had a hidden internal variable, last_environ, that was used in a similar way to __environ_array_list. The application is not impacted by the leak anyway because the relevant operations do not happen in a loop. The change here just uses a separte heap allocation and points environ to that. This means that if an application calls free (environ) and restores the environ pointer to the value at process start, and does not modify the environment further, nothing bad happens. This change should not invalidate any previous testing that went into the original getenv thread safety change, commit 7a61e7f557a97ab597d6 ("stdlib: Make getenv thread-safe in more cases"). The new test cases are modeled in part on the env -i use case from bug 32588 (with !DO_MALLOC && !DO_EARLY_SETENV), and the previous stdlib/tst-setenv-malloc test. The DO_MALLOC && !DO_EARLY_SETENV case in the new test should approximate what userhelper from the usermode package does. Reviewed-by: Carlos O'Donell <carlos@redhat.com> 2025-01-24 09:40:28 +00:00			`#define DO_EARLY_SETENV 1`
			`#define DO_MALLOC 0`
			`#include "tst-environ-change-skeleton.c"`