February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On 2/6/15 3:02 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote: > On Friday, 6 February 2015 at 18:51:34 UTC, Steven Schveighoffer wrote: >> I see the point now that making sure @safe functions don't have >> escapes has the advantage of not requiring *as much* review as a >> @system or @trusted function. I am leaning so much towards H.S. Teoh's >> solution of making @trusted safe by default, and allowing escapes into >> @system code. That seems like the right abstraction. > > Just to make sure that I got this right: > > I don't really understand why you need to escape to @system from > @trusted. Isn't @trusted the same as @system but with a seal that says > that it has been manually verified to be memory safe? @system simply > allows the same internal semantics as @trusted but with no such declared > guarantee to the caller? In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes. I don't have any time to read your further points, but I will catch up with them later, sorry! -Steve |
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 2/6/2015 5:13 AM, Vladimir Panteleev wrote:
> So, to repeat my question: which one is it? Have you changed your mind, or are
> there exceptions to the rules in the post you quoted?
It means that you, the programmer, have to decide whether it is environmental input validation or a logic error in your code.
Follow the rules:
1. exceptions are not for debugging the logic of your program
2. do not use exceptions to recover from logic bugs in your program
I have pontificated on this at GREAT length in multiple threads in this n.g. If it is still a mystery to you or anyone else, I give up. Keep in mind the levels of expertise:
newbie: follow the rules because you're told they're the right thing to do
master: follow the rules because you understand they're the right thing to do
guru: transcend the rules because you know when they don't apply
|
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 2/6/2015 4:17 AM, Kagamin wrote:
> On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
>> On 2/6/2015 12:31 AM, Kagamin wrote:
>>> On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
>>>> static void trustedMemcopy(T[] dest, T[] src) @trusted
>>>> {
>>>> assert(src.length == dest.length);
>>>> memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>>>> }
>>>
>>> Should be enforce: assert doesn't guard against malicious usage.
>>
>> Cue my endless attempts to explain the difference between input errors and
>> logic errors :-(
>
> A little offtop: if this function is compiled in release mode and compiler
> assumes assert holds, it's free to use dest.length instead of src.length and if
> at runtime dest is longer than src, this will create heartbleed-like bug in safe
> code.
Sigh. Please visit your nearest Catholic school and ask one of the nuns to thwack your knuckles with a ruler!
|
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Krejcirik | On 2/6/2015 3:57 AM, Martin Krejcirik wrote:
> If I understand it correctly, Walter is against adding trusted blocks (trusted
> {...}) into @safe functions. But what about having safe blocks in @trusted
> functions ?
>
> int somefunc() @trusted
> {
> int a = systemfunc();
> int b;
>
> @safe {
> b = safefunc(); // calling systemfunc() not allowed;
> }
>
> return a + b;
> }
The problem is, again:
@trusted code must have a safe interface
and with code blocks, there is no interface specified to them other than examining EVERY line of code in it.
The way interfaces are specified in D is to use functions.
|
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On 2/6/2015 8:19 AM, John Colvin wrote:
> Is that what we want? I can't see why not, but it feels off somehow...
> Effectively you've got @trusted blocks in an @trusted function, just inverted.
Right. It just inverted the interface problem, the problem remains. So, no for this idea.
Another way to say it:
@safe => @trusted must go through a safe interface
@trusted => @safe must go through a safe interface
|
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On 2/6/2015 10:58 AM, David Nadlinger wrote:
> @trusted doesn't differ in meaning from @safe for API clients. Both mean that
> you can call the function from @safe code, nothing more, nothing less. I hope we
> agree on that.
That is correct. @trusted is a statement about the implementation of a function, not its interface.
This suggests that @trusted should apply to blocks of code, not function declarations. Pedantically, I think that would be correct. But as we've seen in usage, this seductively makes for easy incorrect usage of @trusted. Pragmatically, the language should make it harder to write incorrect code.
Hence, I view it as the best compromise to make @trusted also apply only at the function level.
|
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote: > In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes. But that can't work: @trusted_is_safe { auto tmp = get_hardware_config(); @system{ mess_up_hardware_config(); } // now this unsafe call is called in a @safe context, but is unsafe... // DMD does not catch this, so "@trusted_is_safe" is broken call_safe_code_that_now_is_messed_up(); @system{ restore_hardware_config(tmp); } } |
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Friday, 6 February 2015 at 21:33:01 UTC, Walter Bright wrote: > On 2/6/2015 10:58 AM, David Nadlinger wrote: >> @trusted doesn't differ in meaning from @safe for API clients. Both mean that >> you can call the function from @safe code, nothing more, nothing less. I hope we >> agree on that. > > That is correct. @trusted is a statement about the implementation of a function, not its interface. > > This suggests that @trusted should apply to blocks of code, not function declarations. Pedantically, I think that would be correct. But as we've seen in usage, this seductively makes for easy incorrect usage of @trusted. Pragmatically, the language should make it harder to write incorrect code. > > Hence, I view it as the best compromise to make @trusted also apply only at the function level. Please see this post: http://forum.dlang.org/post/riphxcqazksykafumzcg@forum.dlang.org |
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 2/6/2015 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
> This is precisely why I have lost all interest in @safe. It's clear that
> the present problematic situation will continue to hold, and the
> decision makers are not interested to address it. I am not going to
> waste any more time and energy on this topic.
In this thread at 8:20PM last night, Dicebot asked me:
"I am not even sure how you can show the example though, to be honest - implied
issues are about maintaining code and not just writing it."
And I replied with a specific example of how to fix one aspect of std.array. There have been no replies. What else can I do to address it?
|
February 06, 2015 Re: @trust is an encapsulation method, not an escape | ||||
---|---|---|---|---|
| ||||
Posted in reply to Zach the Mystic | On 2/6/2015 11:29 AM, Zach the Mystic wrote:
> My attitude is not based on evidence. It's based on just thinking about the
> problem:
>
> http://forum.dlang.org/post/eeglnychgudcffpjcdvy@forum.dlang.org
>
> I really can't answer this question.
You asked:
"Why not force the programmer to tag precisely those portions of his code
which cause him to tag his function @trusted to begin with?"
That question has been asked and answered repeatedly. The answer is that @trusted is not only to TAG unsafe code, but must provide a SAFE INTERFACE to it.
@trusted {
... unsafe code ...
}
provides no indication of what the interface to the unsafe code is. Addressing only the TAG aspect is insufficient.
|
Copyright © 1999-2021 by the D Language Foundation