Jump to page: 1 29  
Page
Thread overview
safety model in D
Nov 03, 2009
Nick Sabalausky
Nov 03, 2009
Nick Sabalausky
Nov 04, 2009
Jesse Phillips
Nov 04, 2009
Aelxx
Nov 04, 2009
Jason House
Nov 04, 2009
Jesse Phillips
Nov 04, 2009
Jesse Phillips
Nov 03, 2009
dsimcha
Nov 03, 2009
Leandro Lucarella
Nov 04, 2009
Bill Baxter
Nov 04, 2009
Leandro Lucarella
Nov 03, 2009
Bill Baxter
Nov 04, 2009
Walter Bright
Nov 04, 2009
Jason House
Nov 04, 2009
Jason House
Nov 04, 2009
Walter Bright
Nov 04, 2009
Leandro Lucarella
Nov 04, 2009
Don
Nov 04, 2009
Don
Nov 04, 2009
Don
Nov 04, 2009
Michel Fortin
Nov 04, 2009
Michal Minich
Nov 04, 2009
Michal Minich
Nov 04, 2009
Michel Fortin
Nov 04, 2009
Michal Minich
Nov 04, 2009
Don
Nov 04, 2009
Michal Minich
Nov 04, 2009
Jesse Phillips
Nov 04, 2009
Leandro Lucarella
Nov 04, 2009
Michal Minich
Nov 04, 2009
Michal Minich
Nov 04, 2009
Michal Minich
Nov 04, 2009
Leandro Lucarella
Nov 04, 2009
Rainer Deyke
Nov 05, 2009
Rainer Deyke
Nov 05, 2009
Rainer Deyke
Nov 05, 2009
Don
Nov 05, 2009
Michal Minich
Nov 05, 2009
Leandro Lucarella
Nov 05, 2009
Jesse Phillips
Nov 06, 2009
Leandro Lucarella
Nov 06, 2009
dsimcha
Nov 06, 2009
Leandro Lucarella
the List example
Nov 06, 2009
Leandro Lucarella
Nov 06, 2009
Max Samukha
Nov 06, 2009
bearophile
Nov 06, 2009
Leandro Lucarella
Nov 05, 2009
Rainer Deyke
Nov 06, 2009
Rainer Deyke
Nov 04, 2009
jpf
Nov 04, 2009
jpf
Nov 05, 2009
Tim Matthews
Re: safety model in D (A quick question)
Nov 06, 2009
AJ
November 03, 2009
SafeD is, unfortunately, not finished at the moment. I want to leave in place a stub that won't lock our options. Here's what we currently have:

module(system) calvin;

This means calvin can do unsafe things.

module(safe) susie;

This means susie commits to extra checks and therefore only a subset of D.

module hobbes;

This means hobbes abides to whatever the default safety setting is.

The default safety setting is up to the compiler. In dmd by default it is "system", and can be overridden with "-safe".

Sketch of the safe rules:

\begin{itemize*}
\item No @cast@ from a pointer type to an integral type and vice versa
\item No @cast@ between unrelated pointer types
\item Bounds checks on all array accesses
\item  No  unions  that  include  a reference  type  (array,  @class@,
  pointer, or @struct@ including such a type)
\item No pointer arithmetic
\item No escape of a pointer  or reference to a local variable outside
  its scope
\item Cross-module function calls must only go to other @safe@ modules
\end{itemize*}

So these are my thoughts so far. There is one problem though related to the last \item - there's no way for a module to specify "trusted", meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me no problem". Many modules in std fit that mold.

How can we address that? Again, I'm looking for a simple, robust, extensible design that doesn't lock our options.


Thanks,

Andrei
November 03, 2009
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:hcqb44$1nc9$1@digitalmars.com...
> SafeD is, unfortunately, not finished at the moment. I want to leave in place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) susie;
>
> This means susie commits to extra checks and therefore only a subset of D.
>
> module hobbes;
>
> This means hobbes abides to whatever the default safety setting is.
>
> The default safety setting is up to the compiler. In dmd by default it is "system", and can be overridden with "-safe".
>
> Sketch of the safe rules:
>
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>   pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>   its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
>
> So these are my thoughts so far. There is one problem though related to the last \item - there's no way for a module to specify "trusted", meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me no problem". Many modules in std fit that mold.
>
> How can we address that? Again, I'm looking for a simple, robust, extensible design that doesn't lock our options.
>

module(system, trusted) calvin;
?


November 03, 2009
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
> module(system) calvin;
> This means calvin can do unsafe things.
> module(safe) susie;
> This means susie commits to extra checks and therefore only a subset of D.
> module hobbes;
> This means hobbes abides to whatever the default safety setting is.
> The default safety setting is up to the compiler. In dmd by default it
> is "system", and can be overridden with "-safe".
> Sketch of the safe rules:
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>    pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>    its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
> So these are my thoughts so far. There is one problem though related to
> the last \item - there's no way for a module to specify "trusted",
> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
> no problem". Many modules in std fit that mold.
> How can we address that? Again, I'm looking for a simple, robust,
> extensible design that doesn't lock our options.
> Thanks,
> Andrei

One comment that came up in discussing GC stuff in Bugzilla:  How do you prevent the following in SafeD?

auto arrayOfRefs = new SomeClass[100];
GC.setAttr(arrayOfRefs.ptr, GC.BlkAttr.NO_SCAN);

foreach(ref elem; arrayOfRefs) {
    elem = new SomeClass();
}
November 03, 2009
dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> SafeD is, unfortunately, not finished at the moment. I want to leave in
>> place a stub that won't lock our options. Here's what we currently have:
>> module(system) calvin;
>> This means calvin can do unsafe things.
>> module(safe) susie;
>> This means susie commits to extra checks and therefore only a subset of D.
>> module hobbes;
>> This means hobbes abides to whatever the default safety setting is.
>> The default safety setting is up to the compiler. In dmd by default it
>> is "system", and can be overridden with "-safe".
>> Sketch of the safe rules:
>> \begin{itemize*}
>> \item No @cast@ from a pointer type to an integral type and vice versa
>> \item No @cast@ between unrelated pointer types
>> \item Bounds checks on all array accesses
>> \item  No  unions  that  include  a reference  type  (array,  @class@,
>>    pointer, or @struct@ including such a type)
>> \item No pointer arithmetic
>> \item No escape of a pointer  or reference to a local variable outside
>>    its scope
>> \item Cross-module function calls must only go to other @safe@ modules
>> \end{itemize*}
>> So these are my thoughts so far. There is one problem though related to
>> the last \item - there's no way for a module to specify "trusted",
>> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
>> no problem". Many modules in std fit that mold.
>> How can we address that? Again, I'm looking for a simple, robust,
>> extensible design that doesn't lock our options.
>> Thanks,
>> Andrei
> 
> One comment that came up in discussing GC stuff in Bugzilla:  How do you prevent
> the following in SafeD?
> 
> auto arrayOfRefs = new SomeClass[100];
> GC.setAttr(arrayOfRefs.ptr, GC.BlkAttr.NO_SCAN);
> 
> foreach(ref elem; arrayOfRefs) {
>     elem = new SomeClass();
> }

Is GC.setAttr a safe function?

Andrei
November 03, 2009
Nick Sabalausky wrote:
> module(system, trusted) calvin;
> ?

Yah, I was thinking of something along those lines. What I don't like is that trust is taken, not granted. But then a model with granted trust would be more difficult to define.

Andrei
November 03, 2009
Andrei Alexandrescu, el  3 de noviembre a las 16:33 me escribiste:
> SafeD is, unfortunately, not finished at the moment. I want to leave in place a stub that won't lock our options. Here's what we currently have:
> 
> module(system) calvin;
> 
> This means calvin can do unsafe things.
> 
> module(safe) susie;
> 
> This means susie commits to extra checks and therefore only a subset of D.
> 
> module hobbes;
> 
> This means hobbes abides to whatever the default safety setting is.
> 
> The default safety setting is up to the compiler. In dmd by default it is "system", and can be overridden with "-safe".

What's the rationale for letting the compiler decide? I can't see nothing but trouble about this. A module will tipically be writen to be safe or system, I think the default should be defined (I'm not sure what the default should be though).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Did you know the originally a Danish guy invented the burglar-alarm unfortunately, it got stolen
November 03, 2009
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:hcqc3m$1pgl$2@digitalmars.com...
> Nick Sabalausky wrote:
>> module(system, trusted) calvin;
>> ?
>
> Yah, I was thinking of something along those lines. What I don't like is that trust is taken, not granted. But then a model with granted trust would be more difficult to define.
>
> Andrei

import(trust) someSystemModule;
?

I get the feeling there's more to this issue than what I'm seeing...


November 03, 2009
Leandro Lucarella wrote:
> Andrei Alexandrescu, el  3 de noviembre a las 16:33 me escribiste:
>> SafeD is, unfortunately, not finished at the moment. I want to leave
>> in place a stub that won't lock our options. Here's what we
>> currently have:
>>
>> module(system) calvin;
>>
>> This means calvin can do unsafe things.
>>
>> module(safe) susie;
>>
>> This means susie commits to extra checks and therefore only a subset of D.
>>
>> module hobbes;
>>
>> This means hobbes abides to whatever the default safety setting is.
>>
>> The default safety setting is up to the compiler. In dmd by default
>> it is "system", and can be overridden with "-safe".
> 
> What's the rationale for letting the compiler decide? I can't see nothing
> but trouble about this. A module will tipically be writen to be safe or
> system, I think the default should be defined (I'm not sure what the
> default should be though).

The parenthesis pretty much destroys your point :o).

I don't think letting the implementation decide is a faulty model. If you know what you want, you say it. Otherwise it means you don't care.


Andrei
November 03, 2009
Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:hcqc3m$1pgl$2@digitalmars.com...
>> Nick Sabalausky wrote:
>>> module(system, trusted) calvin;
>>> ?
>> Yah, I was thinking of something along those lines. What I don't like is that trust is taken, not granted. But then a model with granted trust would be more difficult to define.
>>
>> Andrei
> 
> import(trust) someSystemModule;
> ?
> 
> I get the feeling there's more to this issue than what I'm seeing...

There's a lot more, but there are a few useful subspaces. One is, if an entire application only uses module(safe) that means there is no memory error in that application, ever.

Andrei
November 03, 2009
On Tue, Nov 3, 2009 at 2:33 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> SafeD is, unfortunately, not finished at the moment. I want to leave in place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) susie;
>
> This means susie commits to extra checks and therefore only a subset of D.
>
> module hobbes;
>
> This means hobbes abides to whatever the default safety setting is.
>
> The default safety setting is up to the compiler. In dmd by default it is "system", and can be overridden with "-safe".
>
> Sketch of the safe rules:
>
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>  pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>  its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
>
> So these are my thoughts so far. There is one problem though related to the last \item - there's no way for a module to specify "trusted", meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me no problem". Many modules in std fit that mold.
>
> How can we address that? Again, I'm looking for a simple, robust, extensible design that doesn't lock our options.

I have to say that I would be seriously annoyed to see repeated references to a feature that turns out to be vaporware.  (I'm guessing there will be repeated references to SafeD based on the Chapter 4 sample, and I'm guessing it will be vaporware based on the question you're asking above).  I'd say leave SafeD for the 2nd edition, and just comment that work is underway in a "Future of D" chapter near the end of the book.  And of course add a "Look to <the publishers website || digitalmars.com> for the latest!"

Even if not vaporware, it looks like whatever you write is going to be about something completely untested in the wild, and so has a high chance of turning out to need re-designing in the face of actual use.

--bb
« First   ‹ Prev
1 2 3 4 5 6 7 8 9