On Saturday, 1 June 2013 at 20:22:01 UTC, Nick Sabalausky wrote:
On Sat, 01 Jun 2013 21:59:18 +0200
"monarch_dodra" <monarchdo...@gmail.com> wrote:
The way I understood it, @safe defines a list of things that
are or aren't legal inside the implementation of a function.
It also changes the scheme of bounds checking, in release code.
What bothers me though, is that from an interface point of
view, it doesn't really mean anything (or at least, I haven't
really understood anything). AFAIK: if I call something
"@safe", chances of a core dump are relatively "lower", but
they can still happen:
* A function that accepts a pointer as an argument can be
marked safe, so all bets are off there, no, since the pointer
can be dereferenced?
* Member functions for structs that have pointers, too, can be
marked safe...
Or does it only mean "if you give me valid pointers, I can't
core dump*"?
(*ignoring current flaws, such as escaping slices from static
arrays)
The main reason about this question is that now I'm confused
about @trusted: what are the conditions a developer needs to
take into account before marking a function "@trusted" ?
Ditto for member functions, when they operate on pointer
members. Can those be @safe?
Yeah, overall, I'm confused as to what "@safe" means from an
interface point of view :(
Core dumps aren't the big problem @safe tries to avoid. The big
problem
is memory corruption, ie trampling memory you didn't expect to
(or
shouldn't be allowed to).
So, let's say I have:
--------
void foo(int* p) @safe
{
*p = 0;
}
--------
I suppose that this give foo the liberty of saying "p points to
someplace valid" ... "and if not, it's not my fault"?
I suppose something that is trusted then means "I will not
trample your memory under any circumstance, even if I'm doing
unsafe things under the hood (unless you give a pointer that is
already bad)"?
