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

Subject: Re: [boost] [interprocess] 32-bit offset_ptr
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2019-02-03 14:11:38

Steven Watanabe <watanabesj_at_[hidden]> 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<void, int32_t, int32_t> 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.