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

[Paolo Bonzini]

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].

Paolo