Re: [boost] [interprocess] 32-bit offset_ptr

3 Feb 2019

      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.