bug#13070: Use putenv+unsetenv instead of modifying environ directly

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 07 Dec 2012 20:02:33 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 13070@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> On 12/04/2012 05:51 AM, Fabrice Popineau wrote:
> > Provided I added some unsetenv() function for w32.
> 
> Can you just add $(BLD)/unsetenv.$(O) to GNULIBOBJS
> in lib/makefile.w32-in, or something like that?  No point in
> having two implementations of unsetenv.

I suspect the gnulib implementation won't work for Windows, for the
same reasons the original code you are replacing didn't: it messes
with the environ block, which is allocated on a heap that is different
from the heap used by Emacs.  Even if we don't use the gnulib putenv
implementation, moving pointers in the environ block that belongs to
the Windows runtime library is something I'd like to avoid if
possible.

However, I have just installed in trunk revision 111156 changes that
add to w32.c an implementation of unsetenv, and a wrapper for putenv
that makes it more Posix-compliant.  So you can now commit your
changes, and I believe they will work.

> I've attached a revised patch (sans any change to makefile.w32-in),
> relative to trunk bzr 111151.

Thanks.

> +void
> +xputenv (char const *string)
> +{
> +  if (putenv ((char *) string) != 0)
> +    memory_full (0);
> +}

Shouldn't we refrain from signaling memory_full when errno is EINVAL?
I'd suggest an eassert in that case.  memory_full will emit a
misleading diagnostic.