December 31, 2012
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
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
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
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
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
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
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
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
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
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