I am working with a C API (XCB) which uses void* a lot to obtain parameter packs; these are very small and throwaway so I want them to be allocated to the stack.

Of course, this is valid, but a bit painful:

uint[4] params=[x,y,width,height];
func(params.ptr);

especially when you have lots of calls. now, this compiles:

// (import std.array)
func([x,y,width,height].staticArray.ptr);

but is it well-formed? or is it UB because it is a rvalue and scope ends?
i.e. here is an example program, is it well formed?

import core.stdc.stdio, std.array;

void thing(int* abc) {
  printf("%d\n", *abc);
}

extern(C) void main() {
  thing([1].staticArray.ptr);
}

At any rate, it runs fine consistently with ldc:

$ ldc2 test.d -fsanitize=address
$ ./test
1

I don't know if it is spec-compliant though, or if it is actually causing UB here and I don't notice it.

On Friday, 8 October 2021 at 02:49:17 UTC, codic wrote:

CUDA has something similar that I have to deal with for dcompute[1]. The trick is that the parameter packs always have some sort of underlying structure to them and in D it is possible to exploit that structure at compile time to ensure that you don't break type safety. I can't give a more specific answer without some more concrete examples from XCB, but for CUDA the function signature of the kernel you are trying to launch dictates what goes into the parameter pack.

The best way is to generate (or write) wrapper functions that do this for you such that you can call wrappedFunc(x,y,w,h) and statically verify through its type signature that

is a valid call to func.

uint[4] params=[x,y,width,height];
func(params.ptr);

// (import std.array)
func([x,y,width,height].staticArray.ptr);

For simple types (i.e. ones with no destructor), like int, IIRC this is fine.
When you have a static array of objects that need to be destructed, then end of scope becomes important.

import core.stdc.stdio, std.array;

void thing(int* abc) {
  printf("%d\n", *abc);
}

extern(C) void main() {
  thing([1].staticArray.ptr);
}

$ ldc2 test.d -fsanitize=address
$ ./test
1

note that if the pointer is not escaped from the function (i.e. thing is void thing(scope int* abc)note the addition of scope) LDC will perform promotion of GC allocation to stack of the array literal even if you don't use .staticArray.

https://github.com/libmir/dcompute/blob/master/source/dcompute/driver/cuda/queue.d#L80-L92

On Friday, 8 October 2021 at 05:01:00 UTC, Nicholas Wilson wrote:

On Friday, 8 October 2021 at 05:31:21 UTC, codic wrote:

No, I meant what I said. The array literal will cause a GC allocation, unless it is assigned to a static array of the same length or is inferred to be a static array. The latter happens when you pass it to staticArray because staticArray takes a static array as a parameter and the literal is inferred to be static array instead of a dynamic array, which is the default.

When you don't use staticArray, what happens is LDC looks at the allocation and the fact that the allocated memory does not escape the passed to function (because the argument is annotated with scope) and turns the GC allocated dynamic array literal into a stack allocation (assuming that the array is of sufficiently small size as to not blow the stack).

I guess the point is moot

No, you can still try to use the GC in betterC but you will get a compile time error if you do so. Passing -betterC does not cause GC to stack promotion, it issues errors if you try to use GC (or any other feature that requires druntime like associative arrays or typeinfo).

https://run.dlang.io/is/S8uMbp

It's such a shame that [0,1,2,3].ptr allocates using GC, even if using func(scope const void* ptr)

Can't something be done to make this [0,1,2,3] a static array literal?

Who thought making it GC allocated was a good idea? i want names!

On Friday, 8 October 2021 at 06:59:32 UTC, Nicholas Wilson wrote:

Clears that up, thank you very much for your reply!

On Friday, 8 October 2021 at 14:07:27 UTC, russhy wrote:

No idea, but why isn't just slapping a staticArray sufficient?
I feel your rage, but maybe there was a good reason for it :)

On Friday, 8 October 2021 at 14:07:27 UTC, russhy wrote:

Maybe this is kind of unrelated, but what is happening here and why does it work?

It looks like you've replaced the GC's allocation functions with custom ones, but I couldn't find any documentation on how to do that.

On Saturday, 9 October 2021 at 10:44:30 UTC, Some Guy wrote:

Look in core.memory (https://github.com/dlang/druntime/blob/master/src/core/memory.d)

On Saturday, 9 October 2021 at 10:44:30 UTC, Some Guy wrote:

it is to track and crash whenever there is a GC allocation, usefull when you don't want any GC usage in your code, you put a debugger and you know exactly what is the culprit

here it panics because [0,1,2,3] will allocate usign the GC, wich is not something you want

It should be the other way around, if you want it to be allocated using GC? you should import a package [0,1,2,3].new()