Re: Crash on Windows when SHELL is assigned

[Eli Zaretskii]

> From: Orgad Shaneh <address@hidden>
> Date: Tue, 6 Jun 2017 20:49:26 +0300
> Cc: address@hidden
> 
> > Can you tell why this is a problem?  There's no equivalent of PATHEXT
> > on Posix systems, and no one coded anything like that for Windows.  Is
> > it really such a serious problem?  If so, in what use cases?
> 
> Ah, the PATH lookup I referred to is in #ifdef WINDOWS32.

Yes, but every search along PATH looks for file names, and the file
name on Windows would be with an extension.

> I have a script that calls make with SHELL=sh, and I don't want to
> adapt it (and make it sh.exe) specifically for Windows.

Is that really the only adaptation for Windows you needed to make?
IME, there are a lot of adaptations needed anyway.

> > If we accept that such values of PATH is invalid, then what you
> > describe hits "undefined behavior", and Make is not at fault.  If you
> > disagree, please describe use cases where it is hard or impossible to
> > fix PATH so that it has no quotes.
> 
> I accept it. I just noticed it when I did some experiments to
> workaround the 1st issue :)

OK, let's move on.

> Sorry, I forgot to mention that I refer to command-line argument (make
> SHELL=sh. You can replace sh with anything that doesn't exist like
> make SHELL=fsdfsdf. SHELL=cmd is an exception, since it is handled
> separately, and BTW it does support cmd and cmd.exe). You don't even
> need a Makefile to reproduce the crash.

OK, I see it.  Please try the patch below; if it gives satisfactory
results, I will push it to the Make repository for the next release.

--- variable.c~0        2016-05-21 23:22:32.000000000 +0300
+++ variable.c  2017-06-06 21:36:11.552875000 +0300
@@ -1389,6 +1389,9 @@ do_variable_definition (const floc *floc
         }
     }
   else
+    v = NULL;
+
+  if (!v)
 #endif
 
   /* If we are defining variables inside an $(eval ...), we might have a