I want everything I do to be memory-safe insofar as possible. One of the things I'm doing is communicating to REST services using std.net.curl. std.net.curl isn't marked @safe or @trusted.

Is it possible to have properly memory-safe IO?

Should be possible. Why not?

On Fri, 22 Jan 2016 08:36:14 +0000, Kagamin wrote:

> Should be possible. Why not?

Because almost no IO routines in Phobos are marked @safe, which implies that it's difficult in practice or that people simply haven't done it. I checked std.file, std.net.curl, and std.stdio; a handful of things are @safe while the vast majority aren't.

I want everything I do to be @safe. Unfortunately, "everything I do" includes IO (and std.json), and while it's not sprinkled throughout my code, the call stack has enough variety that I can't mark very much @safe at the end of the day.

At the very least, it would be nice to say: I can't entirely trust some of the code I'm calling, but at least for the code I'm writing here, stop me from doing anything stupid. A @tryToBeSafeIsh, if you will.

On 1/22/2016 9:10 AM, Chris Wright via Digitalmars-d-learn wrote:
> On Fri, 22 Jan 2016 08:36:14 +0000, Kagamin wrote:
>
>> Should be possible. Why not?
>
> Because almost no IO routines in Phobos are marked @safe, which implies
> that it's difficult in practice or that people simply haven't done it. I
> checked std.file, std.net.curl, and std.stdio; a handful of things are
> @safe while the vast majority aren't.
>
> I want everything I do to be @safe. Unfortunately, "everything I do"
> includes IO (and std.json), and while it's not sprinkled throughout my
> code, the call stack has enough variety that I can't mark very much @safe
> at the end of the day.
>
> At the very least, it would be nice to say: I can't entirely trust some
> of the code I'm calling, but at least for the code I'm writing here, stop
> me from doing anything stupid. A @tryToBeSafeIsh, if you will.

Correct, the bug isn't that the documentation is missing about why it's not @safe.  The bug is that a whole lot of phobos (and druntime) should be @safe but the work hasn't been done to mark it as such.  At this point in time, there's not many interesting apps that could mark their main with @safe, which is a real shame.

On Fri, Jan 22, 2016 at 11:15:58AM -0800, Brad Roberts via Digitalmars-d-learn wrote:
> On 1/22/2016 9:10 AM, Chris Wright via Digitalmars-d-learn wrote:
> >On Fri, 22 Jan 2016 08:36:14 +0000, Kagamin wrote:
> >
> >>Should be possible. Why not?
> >
> >Because almost no IO routines in Phobos are marked @safe, which implies that it's difficult in practice or that people simply haven't done it. I checked std.file, std.net.curl, and std.stdio; a handful of things are @safe while the vast majority aren't.
> >
> >I want everything I do to be @safe. Unfortunately, "everything I do" includes IO (and std.json), and while it's not sprinkled throughout my code, the call stack has enough variety that I can't mark very much @safe at the end of the day.
> >
> >At the very least, it would be nice to say: I can't entirely trust some of the code I'm calling, but at least for the code I'm writing here, stop me from doing anything stupid. A @tryToBeSafeIsh, if you will.
> 
> Correct, the bug isn't that the documentation is missing about why it's not @safe.  The bug is that a whole lot of phobos (and druntime) should be @safe but the work hasn't been done to mark it as such.  At this point in time, there's not many interesting apps that could mark their main with @safe, which is a real shame.

@safe still isn't quite there yet, because it doesn't quite prevent all of the things it ought to prevent.

There's actually a way (albeit illegal!) to make main() @safe right now
even when some of the stuff it calls may not be @safe. Here's an
example:

	import std.stdio;
	void unsafeFunc(int x) @system {
		writeln("Buahaha I'm stompin' ur stack");

		version(none) // WARNING: do not uncomment this code at home.
		foreach (i; 0 .. 1000) {
			(&x)[i]++;
		}
	}
	void safeFunc(int x) @safe {
		writeln("I'm safe and innocent!");
	}
	union U
	{
		void function(int) @system func1;
		void function(int) @safe func2;
	}
	void main() @safe // I'm safe!
	{
		U u;
		u.func1 = &unsafeFunc;

		//u.func1(1);	// compiler rejects this, as it should
		u.func2(1);	// compiler accept this, but what is actually called?
	}

This is, of course, a known bug:

	https://issues.dlang.org/show_bug.cgi?id=13536

but my point is, even if you *could* mark main() as @safe today, it still doesn't provide the kind of guarantee you're looking for.  If some of the code you're calling is *untrusted*, how do you know they aren't exploiting loopholes like the above code (intentionally or not -- and keep in mind, this isn't the only safety loophole currently in existence)?


T

-- 
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

On Fri, 22 Jan 2016 11:38:51 -0800, H. S. Teoh via Digitalmars-d-learn wrote:
> @safe still isn't quite there yet, because it doesn't quite prevent all of the things it ought to prevent.

Well, that makes it suboptimal, certainly. But having almost no existing IO options that are @safe makes it unusable, or only marginally usable. I'll take suboptimal over unusable any day.

You can try to write a trusted wrapper for one of curl functions and ask for a review on forum. Maybe it will be fruitful.