Not needed code for mapped files in windows

[lodos@…]

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.

[viboes]

Duplicated #7793