On Fri, Sep 11, 2020 at 10:57:54PM +0200, Christian Weisgerber wrote:
> Otto Moerbeek:
>
> > > Is it possible that char* (env_vers_cstr) points to null or garbage
> > > because env changed? Or is this nonsense and this cannot happen and
> > > env_vers_cstr is always valid with the first match?
> >
> > No, Posix allows previous values of getenv() to be invalidated by
> > subsequenct calls to setenv(), plus a few other conditions.
>
> To clarify: The environment is within the process's address space.
> Neither the parent nor any other process can change it. However,
> the process itself can modify it, which is where putenv() etc. come
> in.
I took a quick look at the file the snippet patches and did not spot
an immediate problem for a single threaded program, the code between
the getenv() call and the use of the return value does not seem to
call setenv() or putenv(). But CMake is multi-threaded and that could
indeed explain occasional failures: one thread is using the return
value from an earlier getenv() call while another thread called
setenv() or putenv().
-Otto