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