Boost C++ Libraries: Ticket #10432: 32-bit offset_ptr crashes on 64-bit platform

attachment set

Andrey Semashev — Sun, 31 Aug 2014 13:13:53 GMT

attachment → offset_ptr_test.cpp

A test case to reproduce the crash

attachment set

Andrey Semashev — Sun, 31 Aug 2014 13:14:12 GMT

attachment → valgrind.log

Valgrind output

Ion Gaztañaga — Wed, 17 Sep 2014 20:02:48 GMT

Using signed integers is problematic because overflow is undefined behaviour, there were problems with some compilers. 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.

Andrey Semashev — Thu, 18 Sep 2014 03:12:12 GMT

Replying to 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?