www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - null allowing safe code to do unsafe stuff.

reply deadalnix <deadalnix gmail.com> writes:
Given a class, that would create a very large object 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.
Mar 18 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 18 2012
parent reply deadalnix <deadalnix gmail.com> writes:
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 ?
Mar 18 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 18 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 18 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Mar 18 2012
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2012-03-18 15:53:42 +0000, deadalnix <deadalnix gmail.com> said:


 Le 18/03/2012 16:30, Andrei Alexandrescu a écrit :

 On 3/18/12 10:19 AM, Timon Gehr wrote:

 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.


On Mac OS X, the protected area is much smaller. 4 Kb I think on Snow 
Leopard 32-bit.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Mar 18 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 18/03/2012 17:18, Michel Fortin a écrit :

 On 2012-03-18 15:53:42 +0000, deadalnix <deadalnix gmail.com> said:


 Le 18/03/2012 16:30, Andrei Alexandrescu a écrit :

 On 3/18/12 10:19 AM, Timon Gehr wrote:

 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.


 On Mac OS X, the protected area is much smaller. 4 Kb I think on Snow
 Leopard 32-bit.


We can page protect the first 64Kb in druntime.
Mar 18 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/18/12 11:18 AM, Michel Fortin wrote:

 On 2012-03-18 15:53:42 +0000, deadalnix <deadalnix gmail.com> said:


 Le 18/03/2012 16:30, Andrei Alexandrescu a écrit :

 On 3/18/12 10:19 AM, Timon Gehr wrote:

 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.


 On Mac OS X, the protected area is much smaller. 4 Kb I think on Snow
 Leopard 32-bit.


I realized I was mistaken. Just looked at 

and it seems the number of fields added by a class is limited to 64K, 
but that's fields not bytes and does not count the fields of the base class.

In order to be safe, a D implementation must figure what is the 
protected area size and insert null checks for all fields accesses that 
go beyond that.


Andrei
Mar 18 2012
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2012-03-18 15:30:44 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Yah, we need to insert a rule that prevents creating class objects 
 larger than 64KB. Java has the same.


The bug you created for that:
<http://d.puremagic.com/issues/show_bug.cgi?id=5176>


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Mar 18 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/18/12 10:15 AM, 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 ?


Safe guarantees your program doesn't have soft memory errors. It can 
still have hard memory errors.

Andrei
Mar 18 2012