Steven Watanabe wrote:

On 2/2/19 9:28 AM, Phil Endecott via Boost wrote:

...

I have some old code that uses 32-bit offset_ptrs, i.e.

typedef boost::interprocess::offset_ptr ptr_t;

This has stopped working on 64-bit systems at some point since 1.58.

...

I'm using these pointers within memory-mapped files which will always be vastly smaller than the 32-bit limit.

The offset_ptr is not restricted to existing inside the memory-mapped file. The library can and does create temporaries.

Thanks Steven & Ion for your replies. I think I was getting away with this because, in general, it is OK to copy an offset_ptr to an out-of-range temporary as long as you don't dereference it before you copy it back. For example: void swap(offset_ptr& a, offset_ptr& b) { offset_ptr tmp = a; a = b; b = tmp; } I think that works, i.e. a and b end up with the correct offsets (provided signed arithmetic is two's complement and wraps around) even though tmp is wrong. On the other hand: offset_ptr offset_ptr::operator++(int) { offset_ptr r = *this; (*this) += 1; return r; } offset_ptr& i = somewhere_in_mapped_file; *(i++) = 42; That fails because the returned offset_ptr on the stack is dereferenced, and points to the wrong place. But we could re-write that to return a regular pointer: pointer offset_ptr::operator++(int) { pointer p = get(); (*this) += 1; return p; } I think most of the offset_ptr methods that return offset_ptr by value can be re-written like that - an exception is pointer_to(). (Does that change mean it is no longer a model of a pointer, or iterator?) Ion, can you comment on whether intrusive containers use (and dereference) temporary pointers? Regards, Phil.