> From: Orgad Shaneh <org...@gmail.com> > Date: Tue, 6 Jun 2017 20:49:26 +0300 > Cc: bug-make@gnu.org > > > 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make