Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at