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.
