Re: Bug in varialbe.c?

[R. Schreuder]

Hi all,

>I believe I have found a bug in variable.c in GNU Make version 3.79.1  When 
>running on Windows NT 4.0 without a sh shell (i.e. having make use the cmd 
>shell), I get the following error:

>P:> d:\TRASH\make-3.79.1\WinDebug\make.exe realclean
>d:\TRASH\make-3.79.1\WinDebug\make.exe: Interrupt/Exception caught (code = 
>0xc0000005, addr = 0x41a44a)

I ran into the same problem, and found Alfred's message in the mailing list 
archive. No responses though. The problem occurs if I have SHELL=/bin/sh in the 
makefile.

>When I make the following change in variable.c, it fixes the problem:

>diff d:\TRASH\make-3.79.1\variable.c d:\TRASH\make-3.79.1.new\variable.c
>1047,1052c1047,1050
><        v = define_variable_loc (expanded_name, strlen (expanded_name),
><                                 default_shell, origin, flavor == f_recursive,
><                                 flocp);
><        no_default_sh_exe = 0;
><     }
><   } else
>---
>>       value = default_shell;
>>       no_default_sh_exe = 0;
>>     } 
>>   } 

>If you look at the original variable.c code, you will see that if the test at 
>line 1046 failes, v is not defined.  Then the Interrupt/Exception is thrown at 
>line 1058.

>Below is a dump of make -v, my environment variables at the time when I ran 
>the version of GNU Make that failes, and the config.h used to compile the code.
>
>Thanks
>-Alfred

Is this the solution? It causes v = define_variable_loc (); (line 1055) in all 
cases, not only (line 1046) if find_and_set_default_shell() succeeds.

1) Given that (#undef __MSDOS__, #undef WINDOWS32) v = define_variable_loc (); 
is done in *all* cases, regardless whether we are dealing with "SHELL" or not, 
Alfred's proposal seems OK.

2) On the other hand (#define __MSDOS__), v = lookup_variable (); (line 1029) 
is performed instead if the shell is not found on a path. Should something 
similar be done for WINDOWS32? Additional question: can lookup_variable () ever 
return NULL here? Than that needs to be handled too (also in __MSDOS__ !).

I'm not familiar enough with the code to decide if none, one or both of the 
alternatives is OK. Can somebody shed some light on this?

Thanks in advance,
Rob Schreuder