Re: Recursive invocation of variable_expand_string bug version 3.80

[Jon Haswell]

Thanks for getting back to me so fast. Just after sending the last email I
found the 3.81beta which I assume has the patch included - at least it does
not exhibit the problem.

Jon Haswell
IBM Research
Tel 408 927 2074 Tie 457 2074
Fax 408 927 3030 Tie 457 3030

Robert Schiele <address@hidden> on 04/01/2004 12:40:23 PM

To:    Jon Haswell/San Jose/address@hidden
cc:    address@hidden, address@hidden
Subject:    Re: Recursive invocation of variable_expand_string bug version
       3.80



On Thu, Apr 01, 2004 at 11:49:42AM -0800, Jon Haswell wrote:
> The problem is in the routine variable_expand_string in how it handles
> access to variable_buffer. When the problem occurs it has been called to
> expand the $(eval $(call ... code above and it does this using the
default
> variable_buffer size of 200. When this routine is called recursively to
> handle expanding the osbasic.d contents the variable_buffer has to be
> expanded as the contents of osbasic.d are over 200 bytes long. This is
done
> by the call to realloc which moves variable_buffer. However when we
return
> to the outer invocation of variable_expand_string it still has its local
> variable 'o', used as the next location in variable_buffer to use, set to
> the old location of variable_buffer before it was expanded/moved. This
then
> leads to some crazy pointer arithmetic and the attempt to allocate some
> very big buffers and hence the error seen.
>
> The somewhat obvious fix for this problem would be to make the return
> function from variable_buffer_output just an offset into the buffer
rather
> than the absolute pointer into the buffer. However this routine is used
so
> frequently and at times in other functions arithmetic is performed
directly
> on variable_buffer that this does not appear to be a simple patch and
some
> one more familiar with this code might be able to suggest a better
> solution.

This is fixed in CVS by putting the buffer pointer on the stack when
entering
the eval function.  Either get the fix from there, or drop me a note, then
I
will send you a patch for 3.80.

Robert

--
Robert Schiele                Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker   mailto:address@hidden