View mode: basic / threaded / horizontal-split · Log in · Help
December 31, 2012
Re: ref is unsafe
I don't understand why there is a discussion on trying to 
special-case ref parameters. There's nothing special about ref 
parameters... what's special is ref _returns_.


Therefore all we need to do is disallow ref returns in @safe code.
December 31, 2012
Re: ref is unsafe
On Monday, 31 December 2012 at 21:25:53 UTC, Mehrdad wrote:
> I don't understand why there is a discussion on trying to 
> special-case ref parameters. There's nothing special about ref 
> parameters... what's special is ref _returns_.
>
>
> Therefore all we need to do is disallow ref returns in @safe 
> code.

Yes, but that will render a whole lot of perfectly safe code, 
including easily provable safe code, from being marked as safe.

The real problem is the ability to return a temp as a ref by 
obfuscating the temp from the compiler through an intermediate 
wrapper of some kind.

Perhaps what must be disallowed (as being @safe) are ref returns 
where the return result cannot be proven to be safe from within 
the calling function, i.e. the wrapper may be safe, but the usage 
of the wrapper cannot be guaranteed to be safe when used as a ref 
return.

--rt
January 01, 2013
Re: ref is unsafe
On Monday, 31 December 2012 at 23:39:35 UTC, Rob T wrote:
> ref returns where the return result cannot be proven to be safe


Halting problem?
January 01, 2013
Re: ref is unsafe
On Monday, December 31, 2012 22:25:52 Mehrdad wrote:
> I don't understand why there is a discussion on trying to
> special-case ref parameters. There's nothing special about ref
> parameters... what's special is ref _returns_.
> 
> Therefore all we need to do is disallow ref returns in @safe code.

The problem is ranges. auto ref returns are _very_ common with the front and 
back of ranges (especially wrapper ranges). If returning by ref or auto ref 
automatically renders code @system, then we just made a _large_ portion of 
Phobos @system when most of it is actually perfectly safe.

We _might_ be able to say that a function is @system if it both takes an 
argument by ref and returns by ref, but even that is likely to be a problem 
unless we can statically prove _in most cases_ that there's no way that the 
ref being returned could be to any portion of any of the arguments passed by 
ref.

- Jonathan M Davis
January 02, 2013
Re: ref is unsafe
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis 
wrote:
> After some recent discussions relating to auto ref and const 
> ref, I have come
> to the conlusion that as it stands, ref is not @safe. It's 
> @system.

This is not a surprise, I remember Andrei was talking about it 
1.5 year ago.

> And I think that we need to take a serious look at it to see 
> what we can do to make
> it @safe. The problem is combining code that takes ref 
> parameters with code
> that returns by ref. Take this code for example:
> <skipped>

I have not met any bugzilla issue or a forum thread when someone 
has fallen in this double ref trap. The only cases I remember are 
discussions that there is such possible problem. Requiring some 
new @attribute or new keyword does not really help, because 
almost all D language constraints can be avoided by low-level 
tricks. Inferring this trap is not always possible as was 
mentioned here because compiler does not always have access to 
function definition.

I think it should not be fixed, but probably compiler may issue 
warning at some circumstances when it can realize this situation.

By the way, there is another issue with ref - 
http://dpaste.dzfl.pl/928767a9 which was discussed several month 
ago minimum. Do you think this should be also fixed?

> But my point is that we currently have a _major_ hole in SafeD 
> thanks
> to the combination of ref parameters and ref return types, and 
> we need to find
> a solution.
>
> - Jonathan M Davis
>

I don't take into D's @safity seriously because it can be easily 
hacked.
January 02, 2013
Re: ref is unsafe
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
> I think it should not be fixed, but probably compiler may issue
> warning at some circumstances when it can realize this situation.

It's a hole in @safe. It must be fixed. That's not even vaguely up for 
discussion. The question is _how_ to fix it. Ideally, it would be fixed in a way 
that limits how much more code has to become @system.

> By the way, there is another issue with ref -
> http://dpaste.dzfl.pl/928767a9 which was discussed several month
> ago minimum. Do you think this should be also fixed?

It's not a bug. You're dereferencing a null pointer, so you get a segfault. 
There's nothing surprising there.

> I don't take into D's @safity seriously because it can be easily
> hacked.

It's fine if you don't care about it, but as the maintainers of the language 
and standard library, we have to take it seriously. Regardless of the 
likelihood of there being a bug caused by this, it breaks @safe, so it must be 
fixed, even if that means simply making all functions which both accept by ref 
and return by ref @system. But that's very undesirable, because it will lead 
to too much code being considered @system even when it's perfectly safe. Hence 
why this is being discussed.

- Jonathan M Davis
January 02, 2013
Re: ref is unsafe
On Wednesday, 2 January 2013 at 19:37:51 UTC, Jonathan M Davis 
wrote:
> On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
>> I think it should not be fixed, but probably compiler may issue
>> warning at some circumstances when it can realize this 
>> situation.
>
> It's a hole in @safe. It must be fixed. That's not even vaguely 
> up for
> discussion. The question is _how_ to fix it. Ideally, it would 
> be fixed in a way
> that limits how much more code has to become @system.

I argue that @safity can be easily broken (not only by example I 
provided) and there is no way to fix all holes because D is a 
system language and provides access to low-level features. @Safe 
is good to warn about (not prevent from) doing something wrong 
but it cannot stop from all safety breakages. Nor it should make 
plenty of code uncompilable just because some trick may cause 
segfault. Actually many things can cause segfaults, but they are 
not intended to be fixed.

>> By the way, there is another issue with ref -
>> http://dpaste.dzfl.pl/928767a9 which was discussed several 
>> month
>> ago minimum. Do you think this should be also fixed?
>
> It's not a bug. You're dereferencing a null pointer, so you get 
> a segfault.
> There's nothing surprising there.

Consider broaden example when function takes pointer, does not 
check for null and passes later reference. This is similar to 
double ref trick.

Consider another example:

---main.d-----
extern(C) void foo() @safe pure nothrow;

void notThatSafe () @safe pure nothrow
{
	foo();
}

void main()
{
	notThatSafe();
}

----foo.d---
extern(C) void foo()
{
	throw new Exception("");
}
----------

So, pure, nothrow and safe are effectively stripped off by 
separate compilation.

Another example, which does not require separate file: 
http://dpaste.dzfl.pl/f968cab5

>> I don't take into D's @safity seriously because it can be 
>> easily
>> hacked.
>
> It's fine if you don't care about it, but as the maintainers of 
> the language
> and standard library, we have to take it seriously. Regardless 
> of the
> likelihood of there being a bug caused by this, it breaks 
> @safe, so it must be
> fixed, even if that means simply making all functions which 
> both accept by ref
> and return by ref @system. But that's very undesirable, because 
> it will lead
> to too much code being considered @system even when it's 
> perfectly safe. Hence
> why this is being discussed.
>
> - Jonathan M Davis

Again, I argue that D is a system language and there are many 
possibilities to break @safity. Although fixing holes does make 
sense in general, it does not make sense fixing obvious issues so 
that plenty of code becomes uncompilable and @safity usage 
becomes very annoying.
January 02, 2013
Re: ref is unsafe
On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> Again, I argue that D is a system language and there are many
> possibilities to break @safity. Although fixing holes does make
> sense in general, it does not make sense fixing obvious issues so
> that plenty of code becomes uncompilable and @safity usage
> becomes very annoying.

Then we're going to have to disagree, and I believe that Walter and Andrei are 
completely with me on this one. If all of the constructs that you use are 
@safe, then it should be _guaranteed_ that your program is memory-safe. That's 
what @safe is for. Yes, it can be gotten around if the programmer marks 
@system code as @trusted when it's not really memory-safe, but that's the 
programmer's problem. @safe is not doing it's job and is completely pointless 
if it has any holes in it beyond programmers mislabeling functions as 
@trusted.

- Jonathan M Davis
January 02, 2013
Re: ref is unsafe
On Wed, Jan 02, 2013 at 05:52:54PM -0500, Jonathan M Davis wrote:
> On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> > Again, I argue that D is a system language and there are many
> > possibilities to break @safity. Although fixing holes does make
> > sense in general, it does not make sense fixing obvious issues so
> > that plenty of code becomes uncompilable and @safity usage becomes
> > very annoying.
> 
> Then we're going to have to disagree, and I believe that Walter and
> Andrei are completely with me on this one. If all of the constructs
> that you use are @safe, then it should be _guaranteed_ that your
> program is memory-safe. That's what @safe is for. Yes, it can be
> gotten around if the programmer marks @system code as @trusted when
> it's not really memory-safe, but that's the programmer's problem.
> @safe is not doing it's job and is completely pointless if it has any
> holes in it beyond programmers mislabeling functions as @trusted.
[...]

All extern(C) functions must be @system by default. It makes no sense to
allow a @safe extern(C) function, since there is no way for the compiler
to verify anything at all. The best you can do is @trusted.


T

-- 
Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"
January 02, 2013
Re: ref is unsafe
On Wednesday, January 02, 2013 15:06:24 H. S. Teoh wrote:
> All extern(C) functions must be @system by default. It makes no sense to
> allow a @safe extern(C) function, since there is no way for the compiler
> to verify anything at all. The best you can do is @trusted.

Agreed. And @trusted is seriously questionable.

- Jonathan M Davis
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home