View mode: basic / threaded / horizontal-split · Log in · Help
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Steven Schveighoffer wrote:
> Sounds 
> good to me.  Should you also be able to mark a whole struct/class as 
> @safe/@trusted, since it's generally a container for member functions?

Yes.

> Care to define some rules for "undefined behavior?"

I suppose I need to come up with a formal definition for it, but it's 
essentially meaning your program is going to do something arbitrary 
that's outside of the specification of the language. Basically, you're 
stepping outside of the domain of the language.

For example, assigning a random value to a pointer and then trying to 
read it is undefined behavior. Casting const away and then modifying the 
value is undefined behavior.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:hcvbu7$9i$1@digitalmars.com...
>
> For example, assigning a random value to a pointer and then trying to read 
> it is undefined behavior.

How would the compiler be able to detect that? Or do you mean assigning an 
arbitrary value?
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
== Quote from Nick Sabalausky (a@a.a)'s article
> "Walter Bright" <newshound1@digitalmars.com> wrote in message
> news:hcvbu7$9i$1@digitalmars.com...
> >
> > For example, assigning a random value to a pointer and then trying to read
> > it is undefined behavior.
> How would the compiler be able to detect that? Or do you mean assigning an
> arbitrary value?

How do you generate a random pointer without casting it from an int (not allowed
in SafeD) or doing pointer arithmetic (not allowed in SafeD)?
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:hcv5p9$2jh1$1@digitalmars.com...
>
> Based on Andrei's and Cardelli's ideas, I propose that Safe D be defined 
> as the subset of D that guarantees no undefined behavior. Implementation 
> defined behavior (such as varying pointer sizes) is still allowed.
>
> 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
>

Sounds great! The lower-grained safeness makes a lot of sense, and I'm 
thrilled at the idea of safe D finally encompassing more than just memory 
safety - I'd been hoping to see that happen ever since I first heard that 
"safeD" only ment memory-safe.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright:

> I agree. Also, dealing with safeness is something that comes later on as 
> a project scales to a larger size. As such, it's more of a nuisance on a 
> small program than a help.

I don't know. In modern languages safety is a starting point. Things are safe unless defined otherwise. In C# default is for safety.


> Right. Adding:
> 
>     @safe:
> 
> at the top will do it.

See my first answer to this thread.

And the same can be said about a modifier 'unsafe' that applies to the whole code of a module. So half of Tango will compile again.

Bye,
bearophile
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
On Thu, 05 Nov 2009 15:20:34 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 05 Nov 2009 14:57:48 -0500, Michel Fortin  
>> <michel.fortin@michelf.com> wrote:
>>
>>> On 2009-11-05 13:33:09 -0500, Walter Bright  
>>> <newshound1@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
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
bearophile wrote:
> 
> In C# you use something like:
> 
> unsafe {
>   // lot of code
> }
> 
> I think that's a good solution. Things are meant as safe unless marked as
> Unsafe. You can mark a whole block of code as unsafe putting it into
> those brackets. D may do the same. Also single functions may have the @unsafe
attribute.
>

That's not the whole story though.

Use an unsafe block and you have to throw the appropriate compiler
switch '/unsafe' and your entire assembly can only be used if it's
'fully trusted'.

Though I forget exactly what that means, 'trust' is determined at
runtime, so e.g. code run from a web browser can't call your assembly.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
safe should be the default. The unsafe part should take the extra
typing, not the other way. Make the user prefer the safe way.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Frank Benoit wrote:
> safe should be the default. The unsafe part should take the extra
> typing, not the other way. Make the user prefer the safe way.

No. D is not C#.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
> news:hcvbu7$9i$1@digitalmars.com...
>> For example, assigning a random value to a pointer and then trying to read 
>> it is undefined behavior.
> 
> How would the compiler be able to detect that? Or do you mean assigning an 
> arbitrary value? 

By disallowing casting an int to a pointer.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home