Re: [Boost-bugs] [Boost C++ Libraries] #10432: 32-bit offset_ptr crashes on 64-bit platform

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #10432: 32-bit offset_ptr crashes on 64-bit platform
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-09-18 03:12:12


#10432: 32-bit offset_ptr crashes on 64-bit platform
-------------------------------+--------------------------
  Reporter: andysem | Owner: igaztanaga
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: interprocess
   Version: Boost 1.56.0 | Severity: Problem
Resolution: | Keywords: offset_ptr
-------------------------------+--------------------------

Comment (by andysem):

 Replying to [comment:1 igaztanaga]:
> Using signed integers is problematic because overflow is undefined
 behaviour, there were problems with some compilers.

 Then I think the sign extension should be coded explicitly. Since
 offset_ptr is supposed to point to locations before itself, the offset is
 logically a signed value (i.e. analogous to ptrdiff_t rather than size_t).

> And yes, offset_ptr was not thought to be used with integers smaller
 than size_t (or more strictly, smaller than uintptr_t). The option to
 customize the OffsetType was to allow interoperability between 32 and 64
 bit applications using 64 bit offset types.
>
> Many times, in a 64 bit OS, a 32 bit offset type can't hold the distance
 between a stack variable and a shared memory address, as the OS can place
 them further than 4GB.
>
> This is not documented and it should be explained.

 If it's absolutely not possible to use offset_ptr with offsets smaller
 than ptrdiff_t then there should be a static assert prohibiting that.

 But I wonder if it's necessary to store offset_ptrs on the stack. Is it
 possible to operate with offset_ptr in-place and only store normal
 pointers on the stack?

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10432#comment:2>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC