November 03, 2009 safety model in D | ||||
---|---|---|---|---|
| ||||
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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | "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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | == 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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | 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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | "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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Leandro Lucarella | 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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 Re: safety model in D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
Copyright © 1999-2021 by the D Language Foundation