Re: EGexecute: don't assume buffer ends in a newline

[Jim Meyering]

Paolo Bonzini wrote:

> On 08/24/2010 03:18 PM, Jim Meyering wrote:
>> Paolo Bonzini wrote:
>>> On 08/24/2010 01:38 AM, Jim Meyering wrote:
>>>> Paolo's concern about BEST_MATCH being *two* past end of buffer
>>>> is valid, but I've convinced myself that even if there is a malloc
>>>> implementation that returns a buffer whose final byte is in the last
>>>> available page, we'd be ok.  That is because of the way the buffer
>>>> size is chosen: adding page size + 1 ensures that an address 1 or 2
>>>> beyond end of buffer will refer to the same page as the last byte.
>>>
>>> My concern is actually that malloc could return a buffer whose final
>>> byte is like 0xFFFFFFFE.  x+buffer_size+1 would be valid, while
>>> x+buffer_size+2 would be NULL.
>>
>> I believe that it is not possible to end up in that situation.
>>
>> 0xFFFFFFFE cannot be one byte past the end of a page boundary.
>>
>> Even if we ignore the ALIGN_TO business,
>
> Yes, I was ignoring it for now.
>
>> and assume that malloc'd blocks are only 4-byte aligned...
>> The base size is 32KiB.  Add to that one page, and then one more byte.
>> The byte that is one past the end of the buffer has an address that
>> is 2 modulo 4.
>
> Yes, that works because you make an assumption on the alignment of
> malloc'd pointers.
>
> Actually I'm okay with Bruno's patch.  I just would like a comment
> somewhere saying "this is not ANSI compliant, but we're doing it
> anyway---if you really care, bump up the size of the buffer by one in
> main.c."
>
> But then, I also would like to understand better the bug that Bruno is
> fixing.  Maybe it can be more easily fixed in main.c, by adding that
> extra byte to the buffer, and putting an eolbyte there just like we do
> with bufbeg[-1].

Agreed to both.
That's why I would like inputs that trigger the bug.
With that, we can more easily evaluate alternatives.