--- Begin Message ---
|
Subject: |
Use putenv+unsetenv instead of modifying environ directly |
|
Date: |
Mon, 03 Dec 2012 12:32:50 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
Tags: patch
The attached patch is in response to last week's thread on emacs-devel
<http://lists.gnu.org/archive/html/emacs-devel/2012-11/msg00514.html>.
It's relative to trunk bzr 111078. Tested on Fedora 17. I don't see
any issues related to the Microsoft port but I'm CC:ing this to Eli
and Fabrice just in case, as the original bug seems to be Windows-related.
setenv.txt
Description: Text document
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Use putenv+unsetenv instead of modifying environ directly |
|
Date: |
Sat, 08 Dec 2012 09:20:57 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 12/08/2012 03:42 AM, Eli Zaretskii wrote:
> 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.
errno cannot be EINVAL, at least not on a POSIXish host:
all strings are allowed as arguments to putenv.
If Microsoft platforms are different it would
make sense to put in an eassert, in w32.c presumably.
I did see a minor problem in the w32.c implementation of unsetenv:
/* MS docs says an environment variable cannot be longer than 32K. */
if (name_len > 32767)
{
errno = ENOMEM;
return -1;
}
unsetenv should return 0 in that case, not -1, since
the variable cannot possibly be in the environment.
This bug doesn't affect Emacs so it's not a pressing one.
I committed the patch as trunk bzr 111158 and am marking
this bug as fixed.
--- End Message ---