The current implementation of CTFE strictly enforces C pointer semantics. One of the restrictions is that you cannot perform ordering comparisons between unrelated pointers.
This is important for repeatability: if it was permitted, the results would be arbitrary and might vary unpredictably with subtle changes in the code, or change between compiler releases.

But, there's an interesting case from bug 7898: the 'inside' operation.
If p and q are pointers to the same array, then (r >= p && r <= q) is true if r points inside that array, and false if it does not.
This seems to be a perfectly reasonable operation: it is completely repeatable and safe, regardless of what r points to. But there doesn't seem to be any way to rewrite it to avoid the disallowed comparisons.

I could write code to allow this special case in CTFE. There's a bit of work to make sure that all the valid cases are detected, because there are quite a lot of ways to rewrite it, but it's not too terrible.

But I dunno, I don't like this sort of thing much. Feels a bit clunky.
OTOH it seems like necessary functionality, and I can't see any other way of doing it.

Opinions?

On 05/25/12 08:50, Don Clugston wrote:
> The current implementation of CTFE strictly enforces C pointer semantics. One of the restrictions is that you cannot perform ordering comparisons between unrelated pointers.
> This is important for repeatability: if it was permitted, the results would be arbitrary and might vary unpredictably with subtle changes in the code, or change between compiler releases.
> 
> But, there's an interesting case from bug 7898: the 'inside' operation.
> If p and q are pointers to the same array, then (r >= p && r <= q) is true if r points inside that array, and false if it does not.
> This seems to be a perfectly reasonable operation: it is completely repeatable and safe, regardless of what r points to. But there doesn't seem to be any way to rewrite it to avoid the disallowed comparisons.
> 
> I could write code to allow this special case in CTFE. There's a bit of work to make sure that all the valid cases are detected, because there are quite a lot of ways to rewrite it, but it's not too terrible.
> 
> But I dunno, I don't like this sort of thing much. Feels a bit clunky.
> OTOH it seems like necessary functionality, and I can't see any other way of doing it.
> 
> Opinions?

It _is_ necessary functionality.
Comparing truly unrelated pointers results in undefined behavior, this is not
different from normal non-ctfe code - i don't see a reason to even bother with
implementing any restrictions. It's undefined, but not unsafe - so the
programmer gets to deal with it.

artur

On 25.05.2012 10:50, Don Clugston wrote:
> The current implementation of CTFE strictly enforces C pointer
> semantics. One of the restrictions is that you cannot perform ordering
> comparisons between unrelated pointers.
> This is important for repeatability: if it was permitted, the results
> would be arbitrary and might vary unpredictably with subtle changes in
> the code, or change between compiler releases.
>
> But, there's an interesting case from bug 7898: the 'inside' operation.
> If p and q are pointers to the same array, then (r >= p && r <= q) is
> true if r points inside that array, and false if it does not.

Isn't indexes just enough for this use case?  It's not like pointer iteration faster/better when you base, end pointer pair.


-- 
Dmitry Olshansky

On Fri, 25 May 2012 02:50:21 -0400, Don Clugston <dac@nospam.com> wrote:

> The current implementation of CTFE strictly enforces C pointer semantics. One of the restrictions is that you cannot perform ordering comparisons between unrelated pointers.
> This is important for repeatability: if it was permitted, the results would be arbitrary and might vary unpredictably with subtle changes in the code, or change between compiler releases.
>
> But, there's an interesting case from bug 7898: the 'inside' operation.
> If p and q are pointers to the same array, then (r >= p && r <= q) is true if r points inside that array, and false if it does not.
> This seems to be a perfectly reasonable operation: it is completely repeatable and safe, regardless of what r points to. But there doesn't seem to be any way to rewrite it to avoid the disallowed comparisons.
>
> I could write code to allow this special case in CTFE. There's a bit of work to make sure that all the valid cases are detected, because there are quite a lot of ways to rewrite it, but it's not too terrible.
>
> But I dunno, I don't like this sort of thing much. Feels a bit clunky.
> OTOH it seems like necessary functionality, and I can't see any other way of doing it.
>
> Opinions?

Remove the restriction.  The code is unpredictable, but not invalid.  It just means you need to take more care when writing such code.

-Steve

On Friday, 25 May 2012 at 14:06:55 UTC, Steven Schveighoffer wrote:
> Remove the restriction.  The code is unpredictable, but not invalid.  It just means you need to take more care when writing such code.

The question is whether we want to allow unpredictable behavior at compile time.

David

On Fri, 25 May 2012 11:08:52 -0400, David Nadlinger <see@klickverbot.at> wrote:

> On Friday, 25 May 2012 at 14:06:55 UTC, Steven Schveighoffer wrote:
>> Remove the restriction.  The code is unpredictable, but not invalid.  It just means you need to take more care when writing such code.
>
> The question is whether we want to allow unpredictable behavior at compile time.

Given the alternative, yes I think we do.

-Steve

I think repeatability of CTFE is much important.
If it is not guaranteed, debugging codes for CTFE is almost impossible.
I hate such special treatments.

And, with CTFEable copy operation, overlapping check is always same as
unrelated memory comparison.
For bug 7898, we should add __ctfe specific code instead of changing
CTFE interpreter.

Kenji Hara

2012/5/25 Don Clugston <dac@nospam.com>:
> The current implementation of CTFE strictly enforces C pointer semantics.
> One of the restrictions is that you cannot perform ordering comparisons
> between unrelated pointers.
> This is important for repeatability: if it was permitted, the results would
> be arbitrary and might vary unpredictably with subtle changes in the code,
> or change between compiler releases.
>
> But, there's an interesting case from bug 7898: the 'inside' operation.
> If p and q are pointers to the same array, then (r >= p && r <= q) is true
> if r points inside that array, and false if it does not.
> This seems to be a perfectly reasonable operation: it is completely
> repeatable and safe, regardless of what r points to. But there doesn't seem
> to be any way to rewrite it to avoid the disallowed comparisons.
>
> I could write code to allow this special case in CTFE. There's a bit of work to make sure that all the valid cases are detected, because there are quite a lot of ways to rewrite it, but it's not too terrible.
>
> But I dunno, I don't like this sort of thing much. Feels a bit clunky.
> OTOH it seems like necessary functionality, and I can't see any other way of
> doing it.
>
> Opinions?
>

On 5/24/2012 11:50 PM, Don Clugston wrote:
> Opinions?


My experience with such special cases is that users lose the ability to reason about what code will work in CTFE and what will not. Its operation will become a magical, unknowable black box. Meanwhile, you'll be endlessly chasing more special cases and rainbows.

I suggest not supporting it unless it can be done in the general case.

One solution might be to attach to each CTFE pointer a reference to the object it is pointing into. Then, pointer comparisons within the same object can work, and comparing pointers from different objects can explicitly and predictably be not supported.

On Friday, 25 May 2012 at 06:50:22 UTC, Don Clugston wrote:
> This is important for repeatability: if it was permitted, the results would be arbitrary and might vary unpredictably with subtle changes in the code, or change between compiler releases.

Wait, what?

Pointer semantics are well-defined... what's wrong with comparing two unrelated pointers?

On 26.05.2012 03:39, Mehrdad wrote:
> On Friday, 25 May 2012 at 06:50:22 UTC, Don Clugston wrote:
>> This is important for repeatability: if it was permitted, the results
>> would be arbitrary and might vary unpredictably with subtle changes in
>> the code, or change between compiler releases.
>
> Wait, what?
>
> Pointer semantics are well-defined... what's wrong with comparing two
> unrelated pointers?

Actually it isn't well-defined in C. You can compare unrelated pointers for equality, but can't compare their ordering.
(I think this is because of the segmented architecture in 16 bit DOS).