ctfe bug?

[Timon Gehr]

On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
> On 2011-12-22 08:47, Johannes Pfau wrote:
>> Hi,
>> the following code is reduced from a parser generated with Ragel
>> (http://www.complang.org/ragel/). That's also the reason why it's
>> using pointers instead of array access, but Ragel guarantees that there
>> won't be any out-of-bound reads.
>>
>> AFAIK pointers are supported in CTFE now as long as they're pointing
>> to an
>> array and there are no out-of-bounds reads. Still, the following code
>> fails:
>>
>> --------------------
>> ubyte[4] testCTFE()
>> {
>> ubyte[4] data;
>> string input = "8ab3060e2cba4f23b74cb52db3bdfb46";
>> auto p = input.ptr;
>> p++; p++;
>> data[0] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> data[1] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> data[2] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> data[3] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> return data;
>> }
>> enum ctfe = testCTFE();
>>
>> void main()
>> {
>> import std.stdio;
>> writeln(testCTFE()); //[138, 179, 6, 14]
>> writeln(ctfe); //[138, 138, 138, 138]
>> }
>> --------------------
>>
>> Has this bug already been filed? I could possibly circumvent it by making
>> ragel use array indexing instead of pointers, but that'd be a performance
>> issue for runtime code as well.
>
> Why would arrays be slower than pointers? You do know that you can turn
> off array bounds checking?
>

Yes but the length has to be stored and updated, therefore for example 
p++ is less machine instructions/memory accesses/register pressure than 
arr = arr[1..$].