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 r = *this;
(*this) += 1;
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 p = get();
(*this) += 1;
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)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk