On Fri, Jan 11, 2002 at 12:54:06AM +1100, Robert Collins wrote: > ----- Original Message ----- > From: "Corinna Vinschen" <[EMAIL PROTECTED]> > > > - getpagesize() should return a value compatible with mmap(), that > is dwAllocGranularity (65536) instead of dwPageSize (1024). > > > > We discussed that months ago. I think we're not going to change that > > (it's 4096, not 1024, btw.). It will result in dubious problems > > when a process mmaps a file. For instance, the latest gcc expects to > > be able to read over the end of an mmaped file if the size is not a > > multiple of getpagesize(). Now think of a file which is > coincidentally > > exactly 1 page long... > > I'm not sure what you are implying. unless getpagesize returns 1, the > behaviour for gcc will be consistent for all larger sizes. If it's 4k, > then a file that is 4k will behave the same way as a 64K file if the > pagesize returned is 64k. > > You seem to be implying that something bad happens when the file size == > the returned page size. > > What is that bad thing?
mmap (MapViewOfFile resp.) alwaus map whole pages. A page is 4096 bytes long. If a file is, say, 8190 bytes, then we have a two page map, size 8192. So we have two trailing 0 bytes. If getpagesize() returns 4096, gcc can count that correctly, if getpagesize returns 65536, gcc assumes 57346 trailing bytes. No problem, gcc only accesses exactly one trailing 0 byte. If the file is 8192 bytes long, mmap maps exactly 8192 bytes, no trailing bytes left. If getpagesize() returns 4096, gcc knows that, if getpagesize returns 65536, gcc assumes 57344 trailing bytes. Now it is a problem, since the one trailing 0 byte doesn't exist. Segmentation fault. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
