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 http://docs.oracle.com/javase/specs/jvms/se5.0/html/ClassFile.doc.html#88659 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