Pointer semantics in CTFE

[Don Clugston]

On 29/05/12 16:20, Michel Fortin wrote:
> On 2012-05-29 13:29:35 +0000, Don Clugston <dac at nospam.com> said:
>
>> On 27/05/12 02:45, Walter Bright wrote:
>>> You could implement it as simply comparing the addresses - you'd be no
>>> worse off than C is, and you would get the correct answer for pointers
>>> both in and out of the array without needing special cases.
>>
>> I think that's a no-go.
>> Implementation-specific behaviour at runtime is bad enough, but at
>> compile time, it's truly horrible. Consider that any change to
>> unrelated code can change the results. Something that makes it really
>> terrible is that the same function can be called in CTFE once before
>> inlining, and once after. Good luck tracking that down.
>> And at runtime, you have a debugger.
>
> Wouldn't it be possible to just catch the case where you compare two
> pointers not assigned from the same memory block and issue an error?
>
> Here's an idea: make each CTFE pointer some kind of struct with a
> pointer to the memory block and an offset. When comparing, if the memory
> block isn't the same, it's an error. If you add or subtract to a
> pointer, it'll still belong to the same memory block but with a
> different offset, thus it remains comparable. When dereferencing, you
> can make sure the pointer still points inside the block, assuming the
> block knows its length.

Thats _exactly_ what it does right now.