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.

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.

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 ?

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.

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

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

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.

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/

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/

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.