On Wednesday, 25 February 2015 at 06:48:17 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 24 February 2015 at 22:49:17 UTC, w0rp wrote:
In general, @trusted means I have proven myself that this
code is actually safe, eeven though it uses unsafe features.
The compiler has to be pessimistic and
On Tuesday, 3 March 2015 at 20:56:50 UTC, w0rp wrote:
The key phrase is guaranteed by the programmer. Which means
that the programmer, not the compiler, is providing a guarantee
that calling a @trusted function will not violate memory
safety. If the programmer cannot make that guarantee, the
Hmm... that means in OOP class is a unit of safety instead of a
method, but it also applies to free methods, which access static
members.
On 3/3/15 9:28 AM, Kagamin wrote:
If one wants to prevent a leak, then counter can be wrapped
---
struct Unsafe(T)
{
private T _payload;
T payload() @system { return _payload; }
alias payload this;
}
---
And somehow disallow Unsafe template in safe function signatures, then
having
If one wants to prevent a leak, then counter can be wrapped
---
struct Unsafe(T)
{
private T _payload;
T payload() @system { return _payload; }
alias payload this;
}
---
And somehow disallow Unsafe template in safe function signatures,
then having
Unsafe!(int*) _counter;
would be ok?
Being a safety measure, it becomes trusted code's responsibility
to provide this safety. BTW it also needs @system postblit; meh,
I hope it's enough to make untouchable.
Unsafe!(int*)* _c;
class A
{
Unsafe!(int*) _counter;
void escape() @safe { _c = _counter; }
}
Not sure if it's legal. It should be really untouchable.
On 3/2/15 3:38 AM, Kagamin wrote:
On Friday, 27 February 2015 at 14:52:56 UTC, Steven Schveighoffer wrote:
The counter is freed in the destructor, nothing can happen after that.
So the code is now etched in stone and cannot be changed? Is there an
attribute for that? :P
Changes introduces
On Friday, 27 February 2015 at 14:52:56 UTC, Steven Schveighoffer
wrote:
The counter is freed in the destructor, nothing can happen
after that.
So the code is now etched in stone and cannot be changed? Is
there an attribute for that? :P
Changes introduces in the destructor shouldn't affect
On Friday, 27 February 2015 at 10:49:25 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 27 February 2015 at 09:33:43 UTC, Kagamin wrote:
If you can't give an example of unsafety easily, that's
already quite important. Compare to C, where one can provide
such an example easily.
Yes, that is true.
On 2/27/15 3:29 AM, Kagamin wrote:
On Thursday, 26 February 2015 at 16:25:59 UTC, Steven Schveighoffer wrote:
However, we have an issue here. At any point inside the code, you
could do:
oldcount = count;
And now, there is still potentially a dangling pointer somewhere. This
means every place
On Friday, 27 February 2015 at 10:49:25 UTC, Ola Fosheim Grøstad
wrote:
2. You construct a transform T(x) that can transform language D
into x.
= D is proven safe.
Eh:
2. You construct a transform T(x) that can transform programs in
language D into P...
On Friday, 27 February 2015 at 08:34:24 UTC, Kagamin wrote:
@safe is supposed to provide safety, if you can give an example
when it doesn't, you can report a bug. There are indeed bugs in
implementation of safety, like escaping of local variables, but
they are supposed to be fixed eventually.
If you can't give an example of unsafety easily, that's already
quite important. Compare to C, where one can provide such an
example easily. If you want to write a mathematical prover, that
won't hurt, though such tools don't need language support, lints
and provers were written even for C.
On Thursday, 26 February 2015 at 16:25:59 UTC, Steven
Schveighoffer wrote:
However, we have an issue here. At any point inside the code,
you could do:
oldcount = count;
And now, there is still potentially a dangling pointer
somewhere. This means every place count is used must be
checked. In
On Thursday, 26 February 2015 at 20:56:52 UTC, Ola Fosheim
Grøstad wrote:
Well, but @safe code is not verified either... It is inferred
@safe based on a fixed set of criterions, but not verified. To
verify you need more, and you have to start with strong typing.
@safe is supposed to provide
On Friday, 27 February 2015 at 09:33:43 UTC, Kagamin wrote:
If you can't give an example of unsafety easily, that's already
quite important. Compare to C, where one can provide such an
example easily.
Yes, that is true. Also, if you are conservative in C++ you also
get pretty good safety
On Thursday, 26 February 2015 at 10:15:07 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 25 February 2015 at 22:59:01 UTC, anonymous wrote:
rule-breaking that's going on there. A public trusted_malloc
would invite the un-initiated to shoot their feet.
That's entirely social...
Sure.
A
On 2/24/15 5:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Since neither Andrei or Walter are able to say something sensible on
these issues when asked, I apparently need to learn something about the
consistency of C memory safety.
I'm happy to listen to
On Thursday, 26 February 2015 at 16:25:59 UTC, Steven
Schveighoffer wrote:
First, malloc should be safe, in the same way new is safe.
If it is typed and do the sizeof...
I would say THIS is somewhat correct:
(() @trusted {free(count); count=null;})();
This takes something that is validly
On Thursday, 26 February 2015 at 12:50:04 UTC, anonymous wrote:
The whole point of @trusted is to be able to call @system code.
It doesn't matter if that code is injected or not. @safe
prevents calling @system code.
But it should matter, because when you mark a unit @trusted you
basically
On 2/26/15 3:49 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 26 February 2015 at 16:25:59 UTC, Steven Schveighoffer wrote:
First, malloc should be safe, in the same way new is safe.
If it is typed and do the sizeof...
Right, one can easily
On Thursday, 26 February 2015 at 20:56:52 UTC, Ola Fosheim
Grøstad wrote:
But it should matter, because when you mark a unit @trusted you
basically are signing off a certificate that says it acts
like @safe in @safe code. How can you verify anything if you
allow injections?
If you allow
On Wednesday, 25 February 2015 at 22:59:01 UTC, anonymous wrote:
rule-breaking that's going on there. A public trusted_malloc
would invite the un-initiated to shoot their feet.
That's entirely social...
You mean the compiler should enforce E to be @safe/@trusted?
That wouldn't happen with an
It improves things without tools. Tools are always welcome, e.g.
dfix already does something.
On Wednesday, 25 February 2015 at 07:07:00 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 25 February 2015 at 00:12:41 UTC, anonymous wrote:
[...]
That sounds more attractive than the provided example, but the
right thing to do is to establish proper encapsulation. That
means you need a
On Wednesday, 25 February 2015 at 18:58:13 UTC, anonymous wrote:
We can't make malloc and free actually memory-safe, can we? We
must not mark public unsafe functions @safe/@trusted.
My point was that there is no conceptual difference between
having a named function trusted_malloc!int() and
On Wednesday, 25 February 2015 at 22:16:14 UTC, Ola Fosheim
Grøstad wrote:
My point was that there is no conceptual difference between
having a named function trusted_malloc!int() and trusted_free()
and wrapping them up individually unnamed.
An ad-hoc declared @trusted malloc is just as
On Wednesday, 25 February 2015 at 09:49:41 UTC, Kagamin wrote:
It's not only code itself to manage here, but also its
evolution:
http://forum.dlang.org/post/mbaksa$1ers$1...@digitalmars.com
That's why it was proposed to change trusted so that it won't
allow implicit usage of system code.
But
On Tuesday, 24 February 2015 at 22:37:58 UTC, Ola Fosheim Grøstad
wrote:
1. My understanding is that @trusted is supposed to give memory
safety escapes by providing a context which reestablish a
memory safety context on return.
Yep, that's how I got it, too. A @trusted function is supposed to
On Tuesday, 24 February 2015 at 22:49:17 UTC, w0rp wrote:
In general, @trusted means I have proven myself that this code
is actually safe, eeven though it uses unsafe features. The
compiler has to be pessimistic and assume that everything which
can be used unsafely will be used unsafely.
On Wednesday, 25 February 2015 at 00:12:41 UTC, anonymous wrote:
If the whole function was @trusted, the compiler wouldn't catch
other safety violations that are not related to malloc/free.
You don't need to. In C++ you use a separate @trusted
data-structure for capturing ownership, aka
Since neither Andrei or Walter are able to say something sensible
on these issues when asked, I apparently need to learn something
about the consistency of C memory safety.
I'm happy to listen to anyone who can explain this to me:
1. My understanding is that @trusted is supposed to give
On Tuesday, 24 February 2015 at 22:37:58 UTC, Ola Fosheim Grøstad
wrote:
If this is careful use of @trusted, then I don't see the point
of having @trusted at all. What is the purpose? What is it
meant to cover? In order for @trusted to make sense in this
code segment (
34 matches
Mail list logo
