What exactly does "@safe" mean?
Nick Sabalausky
SeeWebsiteToContactMe at semitwist.com
Sat Jun 1 13:21:57 PDT 2013
On Sat, 01 Jun 2013 21:59:18 +0200
"monarch_dodra" <monarchdodra at 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).
More information about the Digitalmars-d
mailing list