Testing array ptr for offset 0...

ag0aep6g via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu May 26 15:15:42 PDT 2016


On 05/26/2016 11:13 PM, Era Scarecrow wrote:
>    By adding a struct overload for opOpAssign I can shrink it all down
> to this, and avoid lengths entirely... As such internally the length
> starts at 0, and checks are in place to ensure the bounds are never
> exceeded.
>
>    void scan(ref Data[][] data, Condition cond) {
>      foreach(i; ...) {
>        if (cond)
>          data[i] ~= ...
>      }
>    }

Sorry, I'm still lost. Why can't you do whatever you're doing in 
opOpAssign directly there, or in a free function? Does the pseudo-array 
contain any additional data? Would a wrapper around a built-in array not 
work?

[...]
>   The answer is wrong _because_ the code blows up. I inverted the check
> to check if length is at offset 0 since (the length can only be 1 and a
> better test), however it _still_ gives the wrong answer. Curiously CTFE
> is fine with this casting as long as the pointer stays in that one spot.

Oh, I see. Yeah, the answer is garbage. Seeing the spec section that 
Adam D. Ruppe linked, the length field actually comes first.

That CTFE errors out when you move the pointer to a variable screams 
that something is wrong. The code seems to be seriously misinterpreted 
in CTFE.

----
enum x = () {
     size_t[] arr = [13];
     return *(cast(size_t*) &arr);
} ();
pragma(msg, x);
----

That prints "13LU". Apparently &arr is mistaken for arr here.

I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16081


More information about the Digitalmars-d-learn mailing list