[VDPAU] [PATCH] Save the result from secure_getenv

[Zach Angold]

Thanks for your input, but there seems to be another way we can lose
the result from secure_getenv.

>From the man page for getenv(3):
    The implementation of getenv() is not required to be reentrant.
    The string pointed to by the return value of getenv() may be
    statically allocated, and can be modified by a subsequent call
    to getenv(), putenv(3), setenv(3), or unsetenv(3).

In theory we could run into problems with this since (without this
patch) we use the return value of secure_getenv("VDPAU_DRIVER") after
calling secure_getenv("VDPAU_DRIVER_PATH"). Replacing the other two
occurrences of secure_getenv with safe_secure_getenv has no functional
impact on libvdpau as it is, but it could prevent problems like this
in the future.

-- 
Zach Angold

On Wednesday 17 February 2016 00:22:58 +0200 Rémi Denis-Courmont wrote:
> From: Rémi Denis-Courmont <remi at remlab.net>
> To: vdpau at lists.freedesktop.org
> Subject: Re: [VDPAU] [PATCH] Save the result from secure_getenv
> Message-ID: <42814383.FrDi8JCZNQ at basile.remlab.net>
> Content-Type: text/plain; charset="utf-8"
> 
> On Tuesday 16 February 2016 14:18:14 Zach Angold wrote:
> > The return value from secure_getenv is not guaranteed to be kept after
> > another call to secure_getenv,
> 
> AFAIK, it can only "change" if the environment changes. Changing the process 
> environment should only be done early in main().
> 
> If other threads already exists, it´s undefined behaviour anyway. If libraries 
> (e.g. VDPAU) are already initialized, it´s likewise calling for big troubles.
> 
> So I don´t really see the point in this patch. If you fear that the 
> environment changes, you need atomic access to the environment. And that´s 
> essentially not possible with POSIX :-(
> 
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/