Pointer semantics in CTFE

kenji hara k.hara.pg at gmail.com
Fri May 25 08:48:01 PDT 2012


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 at 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?
>


More information about the Digitalmars-d mailing list