[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10980: GNU bugs information: logs for bug#10980
From: |
Eli Zaretskii |
Subject: |
bug#10980: GNU bugs information: logs for bug#10980 |
Date: |
Sat, 09 Jul 2016 13:57:33 +0300 |
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 29 Jun 2016 19:02:25 -0400
> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se
>
> Ah, I think I missed the idea that changing Vprocess_environment would
> still affect Emacs' environment (technically, what Emacs thinks its
> environment is, which has the same effect). Patch attached.
Thanks, please push to master, after fixing the following minor
issues:
> * src/emacs.c (main): For WINDOWSNT platform, move init_environment
> calls after the set_initial_environment call. This prevents Emacs'
> modifications to the environment from contaminating Vprocess_environment
> and Vinitial_environment (Bug #10980).
Code changes in fragments guarded by preprocessor conditionals should
be formatted like this:
* src/emacs.c (main) [WINDOWSNT]: Move init_environment calls after ...
> * src/callproc.c (getenv_internal): Consult Emacs' internal environment
> in as a fallback to Vprocess_environment on WINDOWSNT platforms.
Same here.
> + *valuelen = strlen(tmpval);
^^^^^^^
Please leave a single blank between a function's name and the
following opening parenthesis.
> + /* Initialize environment from registry settings. Make sure to do
> + this only after calling set_initial_environment so that
> + Vinitial_environment and Vprocess_environment will contain only
> + variables from the parent process without modifications from
> + Emacs. */
Please leave 2 blanks between the last period of the comment text and
the comment terminator "*/".
Bonus points for adding a test for this issue.
- bug#10980: GNU bugs information: logs for bug#10980,
Eli Zaretskii <=