On 12/16/22 7:17 AM, Nick Treleaven wrote:
This code segfaults when the GC calls the dtor after the unittest succeeds:
```d
unittest
{
int i;
struct S
{
~this() { i++; }
}
(*new S).destroy;
}
```
It seems destroy clears the context pointer. Is there a way to te
On Tuesday, 20 December 2022 at 06:31:09 UTC, ag0aep6g wrote:
On 16.12.22 14:07, Nick Treleaven wrote:
This seems to work:
~this() @trusted { if (&i > cast(void*)1024) i++; }
It would be better if there was a struct property to get the
context pointer though.
A quick test suggests
On 16.12.22 14:07, Nick Treleaven wrote:
This seems to work:
~this() @trusted { if (&i > cast(void*)1024) i++; }
It would be better if there was a struct property to get the context
pointer though.
A quick test suggests that the context pointer is the last item in
`tupleof`. So thi
On Friday, 16 December 2022 at 12:17:40 UTC, Nick Treleaven wrote:
This code segfaults when the GC calls the dtor after the
unittest succeeds:
```d
unittest
{
int i;
struct S
{
~this() { i++; }
}
(*new S).destroy;
}
```
It seems destroy clears the context pointer. I
On Friday, 16 December 2022 at 12:17:40 UTC, Nick Treleaven wrote:
It seems destroy clears the context pointer. Is there a way to
test if the context pointer is null in the dtor, to prevent the
increment?
This seems to work:
~this() @trusted { if (&i > cast(void*)1024) i++; }
It woul
This code segfaults when the GC calls the dtor after the unittest
succeeds:
```d
unittest
{
int i;
struct S
{
~this() { i++; }
}
(*new S).destroy;
}
```
It seems destroy clears the context pointer. Is there a way to
test if the context pointer is null in the dtor, t
