bug#24956: 26.0.50; On Windows, setting PATH in compilation-environment has no effect

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 21 Nov 2016 18:19:53 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, 24956@debbugs.gnu.org
> 
> On Sat, Nov 19, 2016 at 2:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >   . I'd rather have the WINDOWSNT-specific code separate (on w32.c),
> >     so perhaps the for-loop you modified could be left intact, and
> >     instead we perform an additional pass over Vprocess_environment,
> >     after it is already copied, to replace these two variables with
> >     their upper-case equivalents, in that special code on w32.c.
> 
> Okay, here is a patch that does that.

Thanks.

> +    /* Make the same modification to `process-environment' which has
> +       already been initialized in set_initial_environment.  */
> +    Lisp_Object env = Vprocess_environment;
> +    Lisp_Object path = build_string ("PATH=");
> +    Lisp_Object path_len = make_number (SBYTES (path));
> +    Lisp_Object comspec = build_string ("COMSPEC=");
> +    Lisp_Object comspec_len = make_number (SBYTES (comspec));
> +    for (; CONSP (env); env = XCDR (env))
> +    {
> +      Lisp_Object entry = XCAR (env);
> +      if (EQ (Fcompare_strings (entry, Qnil, path_len, path, Qnil, Qnil, 
> Qt), Qt))
> +        for (ptrdiff_t i = 0; i < SBYTES (path); i++)
> +          SSET (entry, i, SREF (path, i));
> +      else if (EQ (Fcompare_strings (entry, Qnil, comspec_len, comspec, 
> Qnil, Qnil, Qt), Qt))
> +        for (ptrdiff_t i = 0; i < SBYTES (comspec); i++)
> +          SSET (entry, i, SREF (comspec, i));
> +    }

Why not compare in using _strnicmp instead of Fcompare_strings?  That
would save you the need to cons Lisp strings, and will be more
efficient (Fcompare_strings is quite complex).  Not that speed matters
in this case, but it's just looks strange to me.  Am I missing
something?