Safety, undefined behavior, @safe, @trusted

Steven Schveighoffer schveiguy at yahoo.com
Thu Nov 5 12:59:44 PST 2009


On Thu, 05 Nov 2009 15:20:34 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 05 Nov 2009 14:57:48 -0500, Michel Fortin  
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2009-11-05 13:33:09 -0500, Walter Bright  
>>> <newshound1 at digitalmars.com> said:
>>>
>>>> Safety seems more and more to be a characteristic of a function,  
>>>> rather than a module or command line switch. To that end, I propose  
>>>> two new attributes:
>>>>  @safe
>>>> @trusted
>>>
>>> Looks like a good proposal.
>>>
>>> That said, since most functions are probably going to be safe,  
>>> wouldn't it be better to remove @safe and replace it by its  
>>> counterpart: an @unsafe attribute? This would make things safe by  
>>> default, which is undoubtedly safer, and avoid the unnecessary clutter  
>>> of @safe annotations everywhere.
>>  If unsafe means you cannot pass pointers to local variables, then half  
>> of tango (and other performance oriented libs which use stack  
>> allocation as much as possible) will fail to compile.
>
> While I agree with your point, quick question: could you use ref  
> parameters instead? Ref will be usable in SafeD.

Most of the usages are like this:

ubyte[1024] buffer;
functionThatNeedsBufferSpace(buffer);

where functionThatNeedsBufferSpace takes a ubyte[], thereby taking an  
address of the local data.

So it's not explicit address taking, but it's the same thing under the  
hood.  There always exists the potential for the stack reference to escape.

Similar case is scope classes (which are sometimes used to allocate a  
temporary class for performance in tango).  I can't see scope classes  
being allowed if you can't take addresses of local variables.

I'm not saying that safed needs to allow these kinds of things somehow  
(thereby employing escape analysis), but it might be too restrictive for  
performance-oriented libs/apps.  I think it's acceptable that tango  
eventually gets marked with @trusted, but by making @safe the default, you  
will immediately make many D1 projects not compile without significant  
effort, which might drive away developers from D2, or else make people  
automatically mark all files as @trusted without thinking about it.  By  
defaulting to untrusted and unsafe, you allow people to incrementally add  
@safe and @trusted tags where they are appropriate and correct.

-Steve



More information about the Digitalmars-d mailing list