GNU bug report logs - #13070
Use putenv+unsetenv instead of modifying environ directly

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#13070: closed (Use putenv+unsetenv instead of modifying
 environ directly)
Date: Sat, 08 Dec 2012 17:22:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 08 Dec 2012 09:20:57 -0800
with message-id <50C376F9.3000603 <at> cs.ucla.edu>
and subject line Re: Use putenv+unsetenv instead of modifying environ directly
has caused the debbugs.gnu.org bug report #13070,
regarding Use putenv+unsetenv instead of modifying environ directly
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
13070: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13070
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Use putenv+unsetenv instead of modifying environ directly
Date: Mon, 03 Dec 2012 12:32:50 -0800

[Message part 3 (text/plain, inline)]

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 (text/plain, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13070-done <at> debbugs.gnu.org, fabrice.popineau <at> gmail.com
Subject: Re: Use putenv+unsetenv instead of modifying environ directly
Date: Sat, 08 Dec 2012 09:20:57 -0800

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.