View mode: basic / threaded / horizontal-split · Log in · Help
May 25, 2012
Pointer semantics in CTFE
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?
May 25, 2012
Re: Pointer semantics in CTFE
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
May 25, 2012
Re: Pointer semantics in CTFE
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
May 25, 2012
Re: Pointer semantics in CTFE
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
May 25, 2012
Re: Pointer semantics in CTFE
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
May 25, 2012
Re: Pointer semantics in CTFE
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
May 25, 2012
Re: Pointer semantics in CTFE
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?
>
May 25, 2012
Re: Pointer semantics in CTFE
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.
May 26, 2012
Re: Pointer semantics in CTFE
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?
May 26, 2012
Re: Pointer semantics in CTFE
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).
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home