El 24/02/2011 15:10, Arno Schödl escribió:
Hello Ion, Option 1: Say the requested size is 0x101000000 (4GB+16MB), for example. 32 bit OS would truncate that to 0x1000000 and all allocation/memory mapping calls would succeed (if you have 16MB to spare). Other internal datastructures being 64 bit, they would be set up to show the full 4GB+16MB. This wouldn't work.
I can't see how a 32 bit OS could request 4016MB without detecting the overflow. The managed_shared_memory interface should take std::size_t as size. If the user truncates a 64 bit value to size_t the compiler should issue a warning, it's not interprocess' problem. When connecting to an existing shared memory, the OS should detect the overflow and issue an error if trying to connect a shared memory bigger than 32 bit. mapped_region does this for windows but the check is missing in UNIX (we need to check the return of fstat()-> st_size to be less than the maximum value of std::size_t). I'll add this.
Option 3: The offset_ptr itself must be 64 bit, no question. But its size_type/difference_type do not have to be able to hold the difference between two arbitrary pointers, just between two pointers to the same memory block, which is max 32 bit:
Ok, I missed that. I guess that if shared memory is less than 32 bits, then this would work. I think we should support both approaches: we should be able to use a 64 bit wide smart pointer that can define size_type and difference_type with different types (I guess we could impose size_type to be the unsigned version of difference_type). Offset_ptr should be the customization point for addressing options: memory algorithms and allocators get the addresing configuration from the pointer type, and containers should take the configuration from allocators. Thanks we have templates in the language ;-) Best, Ion