id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
7793,Not needed code for mapped files in windows,lodos@…,Ion Gaztañaga,"The exchange below took place on the boost developer list, it describes the request. Thank you.

> > > When you grow a managed mapped file, the current
> > > implementation fills all the new space with zeroes. This is less
> > > efficient than just resizing the file. The comments in the code
> > > implies there is a reason, so what is  it?
> >

> > Interprocess tries to simulate as much as possible POSIX guarantees.
> > truncate() POSIX system call guarantees that ""If the file is
> extended,
> > the extended area appears as if it were zero-filled"". In windows,
> > SetFileValidData/SetEndOfFile does not zero-fill the extended size so
> > Interprocess needs to write it.

> Given that the mapped file content is not part of the library
> interface, and the only expected user of the mapped file is the library
> itself, why waste time in Windows? Seems to me that a requirement that
> files should be identical is too strong, as long as they work and
> perhaps don't affect platform portability. File portability between
> platforms should be warranted? What about platforms with different
> endianness?

I need to investigate it, but I tried to support similar behaviour for internal file-handling functions. I'll need to think it again. Please fill a ticket so this doesn't get lost when reviewing pending issues.
",Tasks,new,To Be Determined,interprocess,Boost 1.52.0,Optimization,,mapped file grow,