Pointer semantics in CTFE

[Don]

On 26.05.2012 01:09, Walter Bright wrote:
> 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.

That is exactly how it works right now.

The problem is, if pstart and pend point to the beginning and end of an 
array, then given another pointer q, there is AFAIK no defined way in C 
for checking if q is between pstart and pend, even though I'm sure 
everyone does it. (eg, I don't know how to implement memcpy otherwise).
If q is part of that array, (q >= pstart && q <= pend) is well-defined, 
and returns true.
But if it isn't part of that array, q >= pstart is undefined.

In reality of course, if q is unrelated to the array then EITHER q < 
pstart, OR q > pend. So (q >= pstart && q <= pend) is ALWAYS false, and 
the result is completely predictable.

ie, the full expression can be well-defined even though its two 
subexpressions are not.

This can be implemented.
Given an expression like q >= pstart, where p and q are unrelated, it's 
possible to make it have the value 'false_or_undefined'. If it is anded 
with another expression that is also false_or_undefined, and goes the 
other direction ( q <= pend) , then the whole thing is false. Otherwise, 
it generates an error.

The reason it would have to be a special case is because of things like:
bool b = false;
q >= start && ( b = true, true) && q <= end
which is undefined because the result of the first comparison has been 
stored.
So it would only be valid for 
one-comparison-in-each-direction-anded-together (and the equivalent for ||).