bug fix for 3.79 and 3.80

[Steve Brown]

Hi,

I came across a bug today that causes make 3.79 and 3.80  to print 'Malformed per-target variable definition', and sometimes causes it to core-dump on long target names.

The problem is that the eval() function in read.c reallocs memory if you have long target names (>200 chars) put leaves the 'p' pointer at the old address (line 1049 in make-3.80 read.c)

Here's a makefile that reproduces the problem:

% cat makefile

base_metals_fmd_reports.sun5 base_metals_fmd_reports CreateRealPositions CreateMarginFunds deals_changed_since : BUILD_OBJ=$(shell if [ -f "build_information.generate" ]; then echo "$(OBJ_DIR)/build_information.o"; fi )

% make
makefile:3: Malformed per-target variable definition
Segmentation fault

And here's the fix:
% diff -ur read.c ../../make-3.80.new/read.c
--- read.c      Fri Oct  4 12:13:42 2002
+++ ../../make-3.80.new/read.c  Wed Jan 29 17:55:57 2003
@@ -1018,9 +1018,11 @@
         if (*lb_next != '\0')
           {
             unsigned int l = p2 - variable_buffer;
+            unsigned int l2 = p - variable_buffer;
             plen = strlen (p2);
             (void) variable_buffer_output (p2+plen,
                                            lb_next, strlen (lb_next)+1);
+            p = variable_buffer + l2;
             p2 = variable_buffer + l;
           }
 
@@ -1045,9 +1047,11 @@
                after it.  */
             if (semip)
               {
+                unsigned int l2 = p - variable_buffer;
                 *(--semip) = ';';
                 variable_buffer_output (p2 + strlen (p2),
                                         semip, strlen (semip)+1);
+                p = variable_buffer + l2;
               }
             record_target_var (filenames, p, two_colon, v_origin, fstart);
             filenames = 0;

I've submitted patch on savannah: patch id 1022

cheers,
Steve