On Sunday, 10 March 2019 at 14:25:56 UTC, spir wrote:
There is a typo in this instruction:
T* ptr = this.list.getFisrtFreeOrAdd(memViewLen).getPtr!T();
^^
rs
(may this explain your null? the compiler should complain)
diniz
Good catch! But I hav
On 09/03/2019 21:10, ANtlord via Digitalmars-d-learn wrote:
On Saturday, 9 March 2019 at 20:04:53 UTC, Paul Backus wrote:
You can end up with a null `this` reference if you dereference a null pointer
to a struct and then call a method on the result. For example:
I can but my reference is n
On Saturday, 9 March 2019 at 21:00:51 UTC, Ali Çehreli wrote:
I haven't run the code but which pointer is null? Try adding
I mean `this` by "this" word. You can see that `this` is null if
you run gdb and before that line make `p/x this` [0]
this check as wel
On 03/09/2019 12:10 PM, ANtlord wrote:
On Saturday, 9 March 2019 at 20:04:53 UTC, Paul Backus wrote:
You can end up with a null `this` reference if you dereference a null
pointer to a struct and then call a method on the result. For example:
I can but my reference is not null before callin
On Saturday, 9 March 2019 at 20:04:53 UTC, Paul Backus wrote:
struct S
{
bool isThisNull() { return &this is null; }
}
void main()
{
import.std.stdio;
S* p = null;
writeln((*p).isThisNull); // true
}
Interactive version: https://run.dlang.io/is/fgT2rS
Anyway, thank yo
On Saturday, 9 March 2019 at 20:04:53 UTC, Paul Backus wrote:
You can end up with a null `this` reference if you dereference
a null pointer to a struct and then call a method on the
result. For example:
I can but my reference is not null before calling. Take a look at
the line of code [0]
ps://github.com/ANtlord/deadmemory
[1]
https://github.com/ANtlord/deadmemory/blob/master/src/deadmemory/freelist.d#L56
You can end up with a null `this` reference if you dereference a
null pointer to a struct and then call a method on the result.
For example:
struct S
{
bool isThisNull() {
Hello everyone! I've encountered the problem which I already
encountered before. Unfortunately, I had no time in the previous
time to report and to talk about it. So I decided to play making
my own "malloc" function in pure D (betterC) at this time. And I
encountered the issue one more time. `t
On 28-10-17 16:22, Nicholas Wilson wrote:
On Saturday, 28 October 2017 at 14:19:01 UTC, Nicholas Wilson wrote:
As Basile mentioned, this is compiler sticking checks in behind your
back.
The reason it works on new LDC is because #6982 was cherry picked to
LDC (1.3?) before it was merged into dmd
On Saturday, 28 October 2017 at 14:19:01 UTC, Nicholas Wilson
wrote:
As Basile mentioned, this is compiler sticking checks in behind
your back.
The reason it works on new LDC is because #6982 was cherry
picked to LDC (1.3?) before it was merged into dmd (not sure
what version, I though it was 2
;
}
}
void main()
{
A a = null;
B b = null;
auto c = cast(Object)a;
auto d = cast(Object)b; // Fails with:
core.exception.AssertError@test.d(8): null this
}
```
How would you write an opCast that would handle this case
correctly?
Testing if this is null at the
On Saturday, 28 October 2017 at 13:24:49 UTC, Mike Wey wrote:
The following code runs correctly when compiled with ldc
(1.4.0) but fails with an assert error when compiled with dmd
(2.076 and ldc 1.2.0)
```
class A
{
}
class B
{
T opCast(T)()
{
return this;
= null;
auto c = cast(Object)a;
auto d = cast(Object)b; // Fails with:
core.exception.AssertError@test.d(8): null this
}
```
How would you write an opCast that would handle this case correctly?
Testing if this is null at the start of the opCast doesn't help since
the assert is t
13 matches
Mail list logo
