null allowing @safe code to do unsafe stuff.
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Mar 18 08:29:54 PDT 2012
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
More information about the Digitalmars-d
mailing list