July 29, 2012
> On Saturday, July 28, 2012 22:08:42 David Nadlinger wrote:
>> On Saturday, 28 July 2012 at 02:33:54 UTC, Jonathan M Davis But unfortunately wrong – you call S.save in the @trusted block… ;)
>
> Yeah. I screwed that up. I was obviously in too much of a hurry when I wrote
> it. And actually, in this particular case, since the part that can't be
> @trusted is in the middle of an expression doing @system stuff, simply using an
> @trusted block wouldn't do the trick.

Have you guys thought about the possibility that the language could simply not trust any calls that were resolved using a template argument?

I'm a bit tired so I may be missing something, but it seems to me that (in a @trusted template) if the compiler uses an instantiated template parameter (e.g. actual type Foo standing in for template parameter T) to choose a function to call, the compiler should require that the function be @safe, based on the principle that a template cannot vouch for what it can't control. IOW, since a template can't predict what function actually gets called, the compiler should require whatever function gets called to be @safe.

If the programmer actually does want his template function to be able to call _unpredictable_ @system functions, he should mark his template as @system instead of @trusted.
July 29, 2012
On 07/29/12 07:14, David Piepgrass wrote:
>> On Saturday, July 28, 2012 22:08:42 David Nadlinger wrote:
>>> On Saturday, 28 July 2012 at 02:33:54 UTC, Jonathan M Davis But unfortunately wrong – you call S.save in the @trusted block… ;)
>>
>> Yeah. I screwed that up. I was obviously in too much of a hurry when I wrote it. And actually, in this particular case, since the part that can't be @trusted is in the middle of an expression doing @system stuff, simply using an @trusted block wouldn't do the trick.
> 
> Have you guys thought about the possibility that the language could simply not trust any calls that were resolved using a template argument?
> 
> I'm a bit tired so I may be missing something, but it seems to me that (in a @trusted template) if the compiler uses an instantiated template parameter (e.g. actual type Foo standing in for template parameter T) to choose a function to call, the compiler should require that the function be @safe, based on the principle that a template cannot vouch for what it can't control. IOW, since a template can't predict what function actually gets called, the compiler should require whatever function gets called to be @safe.

This wouldn't be enough, and would just paper over the real issue. While the problem is probably most obvious with templates, it is also present when no generics are involved.

If you write a @trusted non-templated function like

   class C { int field; /*...*/ }

   auto f(C c) @trusted { do_something_potentially_unsafe_but_verified_with(c.field); }

it will be fine, as it is all obviously safe, right?

Well, until somebody else later changes 'C' to

   class C { @property field() { return unsafe_buggy_code(); } /*...*/ }

without realizing that 'C.field' is accessed in a @safe context.

The compiler will silently accept it and run the @system code just as if it was marked as @safe or @trusted. The definition of 'C' and the function 'f' could be in different modules or even libraries. Both will still build, without even giving a hint that something may be wrong.

"You can't audit code that isn't available." -- that code may not have been written yet. With the current '@trust' model even an "innocent" access to non-local data can result in all @safe checks being bypassed. Keeping all external accesses out of '@trusted' scopes is not really a practical solution. Most accesses will be (perceived as) safe, so programmers will choose to ignore the potential hazards in order to keep the code readable.

artur
July 29, 2012
Le 28/07/2012 02:08, David Nadlinger a écrit :
> As an example how this is problematic, consider that you are writing a
> function which takes some generic input data, and needs to do (unsafe)
> low-level buffer handling internally to efficiently do its job. You come
> up with a first implementation, maybe only accepting arrays for the sake
> of getting it working quickly, and add @trusted as your dirty buffer
> magic isn't visible from the outside, but does break attribute
> inference. Later, you decide that there is no reason not to take other
> range types as input. Fortunately, the actual implementation doesn't
> require any changes, so you just modify the template constraint as
> needed, and you are good. Well, no – you've just completely broken all
> safety guarantees for every program which calls your function, because
> empty/front/popFront of the passed range might be @system.
>
> Now, you might argue that this is a contrived scenario. Yes, the mistake
> could have easily be avoided, @trusted on a template declaration should
> always raise a red flag.

Run into that exact same problem this week. +1
July 29, 2012
Le 28/07/2012 16:02, Andrei Alexandrescu a écrit :
> This is sensible, but I fail to figure how it adds value over marking
> functions as @trusted. Sure, it's finer-grained, but it's also less
> structured.
>

Let me explain you the a problem I faced this week which illustrate pefectly the problem.

I have a function which is @system. The function caller have to ensure the parameters are correct. If it does, then the function is @trusted as of current semantic.

Let's call that function foo .

I have a second function, bar, which is a template function. This bar function uses reflection on an object and also use foo. The usage of foo is checked, so bar is supposed to be @trusted if all functions called by reflection are @safe or @trusted.

In pseudo code :

void foo(arguments) @system;

void bar(T)(T t) {
    // Reflect T and perform operations, sometime calling reflected methods.

    // call foo with checked arguments.
}

Now, as multiple reflected method can be called, it is really hard to check if bar is @trusted or @safe .

At the end, I ended up not marking the code @trusted which make it @system, even if it is safe in most cases. Simply because it is too difficult to know in which case it is @trusted.

With the proposal, code becomes :

void foo(arguments) @system;

void bar(T)(T t) {
    // Reflect T and perform operations, sometime calling reflected methods.

    @trusted {
        // call foo with checked arguments.
    }
}

The problem is very real and the solution elegant. Any code analyzer will be able to look for @trusted block anyway, as it is certainly a concern to do more code review on @trusted blocks.
February 15, 2013
On 07/28/2012 02:08 AM, David Nadlinger wrote:
>   1) Remove the distinction between @safe and @trusted at the interface
> (ABI, API) level. This implies changing the name mangling of @trusted to
> Nf, and consequently removing the distinction in DMD altogether (at
> least in user-facing parts like .stringof and error messages). In
> theory, this is a breaking change, but as any code that doesn't treat
> them the same is buggy anyway, it shouldn't be in practice. As for
> std.traits.FunctionAttribute, we could either make trusted an alias for
> safe, or just remove documentation for the former and keep it around for
> some time (there is no way to deprecate an enum member).

I haven't read through the whole thread, so pardon if that argument already came up.
I think you're missing an important point here.
SafeD is a subset of the language @trusted is not.
It's very reasonable to implement a compiler that supports only SafeD.
It's probably not feasible to translate @system to javascript for example [1].
Having the distinction at the API level makes perfectly sense for this.
It's also another use case for attribute overloading ;-) [2].

[1]: http://forum.dlang.org/thread/yfmgvgprfpiquakiyjlk@forum.dlang.org#post-yfmgvgprfpiquakiyjlk:40forum.dlang.org

[2]: http://d.puremagic.com/issues/show_bug.cgi?id=9511

February 15, 2013
On 02/15/2013 03:49 AM, David Nadlinger wrote:
> On Fri, Feb 15, 2013 at 3:31 AM, Martin Nowak <code@dawg.eu> wrote:
>> Having the distinction at the API level makes perfectly sense for this.
>
> Sorry, but where is the argument here?
>
> David

If you switch the perspective @trusted allows you to put a constrain on code. Especially you can chose to NOT trust.
The SafeD compiler was not a good example because you have the source code at hand and could inspect it for @trusted blocks.
But if you think of Chromes Native Client it becomes extremely valuable that one could distinguish a function that requires trusting vs. a function that is safe at the ABI level. One could for example intercept and disallow function calls to @trusted functions if a certain plugin is not trusted by the user.
February 15, 2013
On Friday, 15 February 2013 at 04:09:36 UTC, Martin Nowak wrote:
> On 02/15/2013 03:49 AM, David Nadlinger wrote:
> > On Fri, Feb 15, 2013 at 3:31 AM, Martin Nowak <code@dawg.eu>
> wrote:
> >> Having the distinction at the API level makes perfectly
> sense for this.
> >
> > Sorry, but where is the argument here?
> >
> > David
>
> If you switch the perspective @trusted allows you to put a constrain on code. Especially you can chose to NOT trust.
> The SafeD compiler was not a good example because you have the source code at hand and could inspect it for @trusted blocks.
> But if you think of Chromes Native Client it becomes extremely valuable that one could distinguish a function that requires trusting vs. a function that is safe at the ABI level. One could for example intercept and disallow function calls to @trusted functions if a certain plugin is not trusted by the user.

This is totally irrelevant to the current subject, as @trusted code can be called from @safe code.

You are asking for another functionality here.
February 15, 2013
On Friday, 15 February 2013 at 02:31:08 UTC, Martin Nowak wrote:
> ...
> It's probably not feasible to translate @system to javascript for example [1].
> ...

Yes it's feasible.
February 15, 2013
On Friday, 15 February 2013 at 06:27:55 UTC, Timon Gehr wrote:
> On Friday, 15 February 2013 at 02:31:08 UTC, Martin Nowak wrote:
>> ...
>> It's probably not feasible to translate @system to javascript for example [1].
>> ...
>
> Yes it's feasible.

http://asmjs.org/spec/latest/
February 16, 2013
On Saturday, 28 July 2012 at 00:08:30 UTC, David Nadlinger wrote:
> @trusted in its current form needs to go. Its design is badly broken, as it leaks implementation details and encourages writing unsafe code.
>
> The Problem
> ———————————
>
> [...]
>
> A Solution
> ——————————
>
> Let me make something clear first: I am _not_ intending to remove @trusted from the language. As a bridge between the @safe and @system worlds, it is an integral part of SafeD. What I'm proposing is:
>
>  1) Remove the distinction between @safe and @trusted at the interface (ABI, API) level. This implies changing the name mangling of @trusted to Nf, and consequently removing the distinction in DMD altogether (at least in user-facing parts like .stringof and error messages). In theory, this is a breaking change, but as any code that doesn't treat them the same is buggy anyway, it shouldn't be in practice. As for std.traits.FunctionAttribute, we could either make trusted an alias for safe, or just remove documentation for the former and keep it around for some time (there is no way to deprecate an enum member).
>
>  2) The first step is necessary, but mainly of cosmetic nature (think `pure`, `pure2`). We still need to address for the granularity and attribute inference problem. The obvious solution is to add a "@trusted" declaration/block, which would allow unsafe code in a certain region. Putting @trusted in the function header would still be allowed for backwards compatibility (but discouraged), and would have the same effect as marking the function @safe and wrapping its whole body in a @trusted block. It could e.g. look something like this (the @ prefix definitely looks weird, but I didn't want to introduce a new keyword):
>
> ---
>  void foo(T)(T t) {
>    t.doSomething();
>    @trusted {
>      // Do something dirty.
>    }
>    t.doSomethingElse();
>    @trusted phobosFunctionWhichHasNotBeenMarkedSafeYet();
>  }
> ---
>
> This is similar to other constructs we have today, for example debug {}, which allows impure code. It can be debated whether a block »argument« should introduce a new scope or not (like static if). The latter currently seems much more attractive to me, but I suppose it could be confusing for some.
>
> In any case, while there is probably quite a bit of bikeshedding to be done for 2), I don't think there is much controversy about 1). So, let's try to get this done shortly after the 2.060 release – as discussed above, it is very unlikely that the change will break something, but the odds still increase over time. Also, there is currently a Phobos pull request [4] which will be influenced by the outcome of this discussion.


I completely agree with the above. @trusted should be applied to as small blocks of code as possible -- preferably to individual statements -- to make it easier for the programmer to verify and maintain the safety of the code.

Lars
1 2 3 4
Next ›   Last »