Re: Pointer semantics in CTFE

On 05/29/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.
> 

   int a[1024];
   int[] da = a[0..1024];

   if (whatever)
      da = da[3..14];
   if (something_else)
      da = [42] ~ da;
   // etc

   if (da_is_a_slice_of_a())
      still_inside_a();

How do you implement da_is_a_slice_of_a()?

Disallowing pointer comparisons means normal code needs __ctfe special
casing in order to work at compile time at all, like it was done for the
"bug" mentioned in this thread.

artur