Le 18/03/2012 16:30, Andrei Alexandrescu a écrit :
On 3/18/12 10:19 AM, Timon Gehr wrote:
On 03/18/2012 04:15 PM, deadalnix wrote:
Le 18/03/2012 15:24, Timon Gehr a écrit :
On 03/18/2012 02:54 PM, deadalnix wrote:
Given a class, that would create a very large object
This is the culprit.
if instantiated,
and a null reference, you can access memory in « raw mode ». This is
@safe D code, but really isn't.
As solution, @safe code should insert tests for null reference, or
should prevent null to be used.
This is fighting symptoms.
@safe is supposed to be a guarantee. And, even if it is bad practice, in
this case we aren't able to ensure that these guarantee are respected.
Given that, @safe doesn't guarantee anything. You may think that this
isn't a problem, but, what is the point of @safe if it is unable to
ensure anything ?
No null checks are necessary as long as there is no class that would
create such a very large object.
Yah, we need to insert a rule that prevents creating class objects
larger than 64KB. Java has the same.
Andrei
This is another solution. In this case, we have to ensure that the first
64kb of the system are page protected to detect null pointer deference
in druntime.
