www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Obtain pointer from static array literal

reply codic <codic linuxmail.org> writes:
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:
```d
uint[4] params=[x,y,width,height];
func(params.ptr);
```
especially when you have lots of calls. now, this compiles:
```d
// (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?
```d
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.
Oct 07 2021
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 8 October 2021 at 02:49:17 UTC, codic wrote:

 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.


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


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


is a valid call to func.


 Of course, this is valid, but a bit painful:
 ```d
 uint[4] params=[x,y,width,height];
 func(params.ptr);
 ```
 especially when you have lots of calls. now, this compiles:
 ```d
 // (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?


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.


 i.e. here is an example program, is it well formed?
 ```d
 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.


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
Oct 07 2021
parent reply codic <codic linuxmail.org> writes:
On Friday, 8 October 2021 at 05:01:00 UTC, Nicholas Wilson wrote:

 For simple types (i.e. ones with no destructor), like int, IIRC 
 this is fine.


Thanks, perfect!

 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.


Interesting, I think you meant "even if you do use .staticArray"; 
not sure why it would do that, but it doesn't matter because my 
code is betterC and therefore nogc so it *should* allocate it on 
the stack, I think
Oct 07 2021
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 8 October 2021 at 05:31:21 UTC, codic wrote:

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

 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.





 Interesting, I think you meant "even if you do use 
 .staticArray";


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.


 not sure why it would do that,


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).


 but it doesn't  matter because my code is betterC


I guess the point is moot


 and therefore nogc so it  *should* allocate it on the stack, I 
 think


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).
Oct 07 2021
next sibling parent reply russhy <russhy gmail.com> writes:
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!
Oct 08 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 8 October 2021 at 14:07:27 UTC, russhy wrote:

 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!


No idea, but why isn't just slapping a staticArray sufficient?
I feel your rage, but maybe there was a good reason for it :)
Oct 09 2021
prev sibling parent reply Some Guy <someguy mailinator.com> writes:
On Friday, 8 October 2021 at 14:07:27 UTC, russhy wrote:

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


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.
Oct 09 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 9 October 2021 at 10:44:30 UTC, Some Guy wrote:

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

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


 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.


Look in core.memory 
(https://github.com/dlang/druntime/blob/master/src/core/memory.d)
Oct 09 2021
parent Some Guy <someguy mailinator.com> writes:
On Saturday, 9 October 2021 at 13:11:29 UTC, Imperatorn wrote:

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


Does this technique work for all D runtime (or std) functions? 
Can we just define what the function is and then the compiler 
uses our definition instead of the definition inside the runtime?

I would've thought that our definition is just another overload 
but I guess `extern(C)` prevents that.
Oct 09 2021
prev sibling parent russhy <russhy gmail.com> writes:
On Saturday, 9 October 2021 at 10:44:30 UTC, Some Guy wrote:

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

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


 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.


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



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


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()
Oct 09 2021
prev sibling parent codic <codic linuxmail.org> writes:
On Friday, 8 October 2021 at 06:59:32 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.

 [...]


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