Re: [boost] interest in a stateful pointer library?

Subject: Re: [boost] interest in a stateful pointer library?
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2017-10-09 12:34:27

Hi Peter,

> On 9. Oct 2017, at 11:37, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
>> This is kinda sad, because the library is much less useful if tagged_ptr is not guaranteed to work on all platforms now and in the future. Just assume you use this in a large project and rely on it, and then a new processor generation comes out where tagged_ptr does not work anymore. That being said it is probably still useful for special projects, but not something to put in Boost. :(
> 
> On the contrary, this is exactly why it needs to be put in Boost - to isolate the platform-specific differences behind a portable interface.

ok, if you put it that way, I will not disagree. :) It would be nice to have a portable interface for a tagged_ptr. I am not sure, what kind of guarantees this pointer could offer for a new platform that is not supported yet. Boost.Align has a nice fallback solution for not-yet-supported systems. I thought I could ride piggy-back on that feature with this library, but as the Redditors pointed out, it is not that simple.

>> but smart people on Reddit showed me that I am relying on undefined behaviour here.
> 
> Out of curiosity, what's the specific problem that was pointed out? What behavior is undefined?

I was pointed to this answer on SO:
https://stackoverflow.com/questions/34737737/relation-between-numeric-representation-of-memory-address-and-alignment

I am relying on two things:
- memory addresses map trivially to consecutive integers
- the address of aligned memory allocated by Boost.Align always converts into an integer that is a multiple of the alignment value

Neither seems to be guaranteed by the standard. The conversion from memory address to integer is an implementation detail, the SO answer gives examples of "exotic" mappings which are conceivable (not that there is any machine out there which actually does it this way). Concerning the second point, there is no guarantee that the integer is an exact multiple of the alignment value, there could be an offset, too. The offset could depend on the platform, which would be a minor problem for predictability, or even on the memory segment from which the memory was allocated… then it would be impossible to predict and tagged_ptr falls flat.

Best regards,
Hans