http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #50 from Steven Schveighoffer <schveiguy@yahoo.com> 2012-06-04 11:35:27 PDT ---
(In reply to comment #47)
> Common! System language must have strict rights. You just have said that D is JavaScript.

A systems language is very strict as long as you play within the type system.

Once you use casts, all bets are off.  The compiler can make *wrong assumptions* and your code may not do what you think it should.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #51 from Steven Schveighoffer <schveiguy@yahoo.com> 2012-06-04 11:48:22 PDT ---
(In reply to comment #48)
> (In reply to comment #46)
> > (In reply to comment #45)
> > > If a @trusted function accepts a pointer, it must _under no circumstances_ access anything except for the pointer target, because it can be called from @safe code.
> > 
> > The point of @trusted is that it is treated as @safe, but can do unsafe things.
> >  At that point, you are telling the compiler that you know better than it does
> > that the code is safe.
> > 
> > The compiler is going to assume you did not access anything else beyond the target, so you have to keep that in mind when writing a @trusted function that accepts a pointer parameter.
> > 
> > Off the top of my head, I can't think of any valid usage of this, but it doesn't mean we should necessarily put a restriction on @trusted functions. This is a systems language, and @trusted is a tool used to circumvent @safe-ty when you know it is actually @safe.
> 
> Sorry, but I think you got this wrong. Consider this example:
> 
> ---
> void gun(int* a) @trusted;
> 
> int fun() @safe {
>   auto val = new int;
>   gun(val);
>   return *val;
> }
> ---
> 
> Here, calling gun needs to be safe under _any_ circumstances.

No, it does not.  Once you use @trusted, the compiler stops checking that it's @safe.

> Thus, the only
> memory location which gun is allowed to access is val. If it does so by
> evaluating *(a + k), where k = (catalanNumber(5) - meaningOfLife()), that's
> fine, it's @trusted, but ultimately k must always be zero. Otherwise, it might
> violate the memory safety guarantees that need to hold for fun(). This is
> definitely not »defined by the programmer, and not expressed in possible way to
> the type system or the compiler«.

Yeah, that's a hard one to spell out in docs.  I'd recommend not writing that function :)

But there's no way to specify this to the compiler, it must assume you have communicated it properly.

Here is an interesting example (I pointed it out before in terms of sockaddr):

struct PacketHeader
{
   int nBytes;
   int packetType;
}

struct DataPacket
{
   PacketHeader header = {packetType:5};
   ubyte[1] data; // extends through length of packet
}

How to specify to the compiler that PacketHeader * with packetType of 5 is really a DataPacket, and it's data member has nBytes bytes in it?

Such a well-described data structure system can be perfectly @safe, as long as you follow the rules of construction.

Now, in order to ensure any function that receives a PacketHeader * is @trusted, you will have to control construction of the PacketHeader somehow. Perhaps you make PacketHeader an opaque type, and @safe functions can therefore never muck with the header information, or maybe you mark nBytes and packetType as private, so it can never be changed outside the module that knows how to build PacketHeaders.  In any case, it is wrong to assume that there isn't a valid way to make a @trusted call that is free to go beyond the target.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #52 from Steven Schveighoffer <schveiguy@yahoo.com> 2012-06-04 11:51:14 PDT ---
(In reply to comment #49)
> It seems that the compiler will only optimize based on "pureness" if a function takes an 'immutable T*' argument, even 'immutable(T)*' is enough to turn the optimization off.

This is a bug, both should be optimized equally:

void foo(immutable int * _param) pure
{
   immutable(int)* param = _param; // legal
   ... // same code as if you had written void foo(immutable(int)* param)
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #53 from klickverbot <code@klickverbot.at> 2012-06-04 12:12:16 PDT ---
(In reply to comment #51)
> (In reply to comment #48)
> > Here, calling gun needs to be safe under _any_ circumstances.
> 
> No, it does not.  Once you use @trusted, the compiler stops checking that it's @safe.

Yes, it does. As you noted correctly, you as the one implementing gun() must take care of that, the compiler doesn't help you here. But still, you must ensure that gun() never violates memory safety, regardless of what is passed in, because otherwise it might cause @safe code to be no longer memory safe.

> Now, in order to ensure any function that receives a PacketHeader * is
> @trusted, you will have to control construction of the PacketHeader somehow. […]

Okay, iff you are using a pointer more or less exclusively as an opaque handle, then I guess you are right – I thought only about pointers that are directly obtainable in @safe code.

But then, please be careful with including something along the lines of »For @safe functions, the compiler should allow access only to the specific item pointed to as defined by the pointed-at type, and nothing else« in the docs, because it is quite misleading (or even technically wrong, although I know what you are trying to say): A @safe function _can_ in effect access other memory, if only with the help from a @trusted function.

On a related note, the distinction between @safe and @trusted (especially the difference in mangling) is a horrible abomination and should die in a fire. @safe and @system are contracts, @trusted is an implementation detail – mixing them makes no sense.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #54 from klickverbot <code@klickverbot.at> 2012-06-04 12:14:40 PDT ---
(In reply to comment #52)
> This is a bug, both should be optimized equally:
> 
> void foo(immutable int * _param) pure
> {
>    immutable(int)* param = _param; // legal
>    ... // same code as if you had written void foo(immutable(int)* param)
> }

Yep, both should be recognized PUREstrong in DMD – if not, please open a new bug report for that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #55 from Steven Schveighoffer <schveiguy@yahoo.com> 2012-06-04 13:34:50 PDT ---
(In reply to comment #53)
> (In reply to comment #51)
> > (In reply to comment #48)
> > > Here, calling gun needs to be safe under _any_ circumstances.
> > 
> > No, it does not.  Once you use @trusted, the compiler stops checking that it's @safe.
> 
> Yes, it does. As you noted correctly, you as the one implementing gun() must take care of that, the compiler doesn't help you here. But still, you must ensure that gun() never violates memory safety, regardless of what is passed in, because otherwise it might cause @safe code to be no longer memory safe.

I think I misunderstood your original point.  I thought you were saying that gun must be *prevented from* modifying other memory relative to its parameter. Were you simply saying that gun is not stopped by the compiler, but must avoid it in order to maintain safety?  If so, I agree, for your example.

I can also see that my response was misleading.  I did not mean it should not be safe, I meant it's not enforced as safe.  Obviously something that is @trusted needs to maintain safety.

> On a related note, the distinction between @safe and @trusted (especially the difference in mangling) is a horrible abomination and should die in a fire. @safe and @system are contracts, @trusted is an implementation detail – mixing them makes no sense.

I'm not sure what you're saying here, but @trusted is *definitely* needed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #56 from github-bugzilla@puremagic.com 2012-07-01 23:12:33 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/d-programming-language.org

https://github.com/D-Programming-Language/d-programming-language.org/commit/59670a7823d066f5146e276bdf5aac7bd93a3f45 Fix for issue# 8185.

This clarifies the definition of pure, since so many people seem to have a hard time understanding that _all_ that pure means is that the function cannot access global or static, mutable state or call impure functions. Everything else with regards to pure is a matter of implementation-specific optimizations - which does in some cases relate to full, functional purity, but pure itself does not indicate anything of the sort.

https://github.com/D-Programming-Language/d-programming-language.org/commit/8cc3ba694bc07ec684f2d1c5a088728aa18e7d93 Merge pull request #128 from jmdavis/pure

Fix for issue# 8185.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8185


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------