On Fri, Feb 03, 2023 at 04:23:32PM +0000, David Laight wrote: > From: Matthew Wilcox > > "The system shall always zero-fill any partial page at the end of an > > object. Further, the system shall never write out any modified portions > > of the last page of an object which are beyond its end. References > > within the address range starting at pa and continuing for len bytes to > > whole pages following the end of an object shall result in delivery of > > a SIGBUS signal." > > > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html > > It also says (down at the bottom of the rational): > > "The mmap() function can be used to map a region of memory that is larger > than the current size of the object. Memory access within the mapping but > beyond the current end of the underlying objects may result in SIGBUS > signals being sent to the process. The reason for this is that the size > of the object can be manipulated by other processes and can change at any > moment. The implementation should tell the application that a memory > reference is outside the object where this can be detected; otherwise, > written data may be lost and read data may not reflect actual data in the > object." > > There are a lot of 'may' in that sentence. > Note that it only says that 'data written beyond the current eof may be > lost'. > I think that could be taken to take precedence over the zeroing clause > in ftruncate(). How can the _rationale_ (explicitly labelled as informative) for one function take precedence over the requirements for another function? This is nonsense. > I'd bet a lot of beer that the original SYSV implementation (on with the > description is based) didn't zero the page buffer when ftruncate() > increased the file size. > Whether anything (important) actually relies on that is an interesting > question! > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >
