dynamically sized, stack-allocated arrays cause segfaults at compile time

[porky11]

This works in c:

#include <stdio.h>

void main() {
  int x = 1;
  float y[x];
  printf("no error?");
}

This should do the same in dale:

(import stdlib)

(def main (fn extern-c void (void)
  (let ((x \ 1)
        (y (array-of x float)))
    (printf "no error?\n"))))

This causes segfault at compile time. The c version also works, if x isn't constant. The problem in dale may also be, that arrays of different sizes are different types unlike in c. There are some solutions:

• don't allow stack-allocated arrays of unknown size (no good option, since it is possible, but better than segfaults)
• add unsized arrays for this case (maybe (array-of 0 T))
• let all arrays be unsized types ((array-of T))
• let arrays be equivalent to pointers for unknown size (seems too irregular)
• let arrays be equivalent to pointers anytime (also a nice solution, since it's similar to c, and currently some array-casting and arrays as functions are weird. The Array concept will be enough for this)

[BitPuffin]

Actually I believe your example C code isn't standard compliant. But some compilers support usage like that anyway.

As for Dale, I think I oppose pretty much all your suggestions. I think generally your last option listed with how C acts is generally considered a weakness of C[1]. If I'm not mistaken (array-of n T) is a static type. So (array-of 2 int) and (array-of 3 int) are two separate types, and no runtime data is allocated for the length. If I'm right, then this is good, much like std::array in C++, which fixes the issue with native C-style arrays.

For a dynamically allocated array I think that should be its own type. Call it sequence or something like that. Which will allocate on the stack (because otherwise you may as well use vector), and also allocate a number for holding the element count. You can probably implement this as a library since there are OS functions for arbitrary stack allocation (see alloca). And implement the copy semantics etc. Free it when it goes out of scope in the destructor [edit: actually is that even necessary/possible?].

Also, if you implement such a type, is there any reason to not allow it to grow dynamically? It can basically be a stack-vector Like why not.

[1] http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625

[porky11]

I don't think, when something is allocated on stack, it's possible to dynamically resize it.

[BitPuffin]

Yeah I guess not, it would work in theory if it was the element at the top of the stack. But that's probably usually not the case. So yeah good correction :P to be fair I wrote that at like 2am x)

[tomhrr]

Thanks, there was a problem with how the size expression was being evaluated, and that's now been fixed. I think the suggested alloca approach is the best one here, if VLAs are needed, since adding VLAs as a language-level feature is fairly complex (for each of the original suggested solutions) while bringing little additional benefit.