--- Comment #53 from klickverbot <> 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:
------- You are receiving this mail because: -------

Reply via email to