Safety, undefined behavior, @safe, @trusted

dsimcha dsimcha at yahoo.com
Thu Nov 5 20:45:29 PST 2009


== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> Steven Schveighoffer wrote:
> > Sounds
> > good to me.  Should you also be able to mark a whole struct/class as
> > @safe/@trusted, since it's generally a container for member functions?
> Yes.
> > Care to define some rules for "undefined behavior?"
> I suppose I need to come up with a formal definition for it, but it's
> essentially meaning your program is going to do something arbitrary
> that's outside of the specification of the language. Basically, you're
> stepping outside of the domain of the language.
> For example, assigning a random value to a pointer and then trying to
> read it is undefined behavior. Casting const away and then modifying the
> value is undefined behavior.

What about threading?  I can't see how you could statically prove that a
multithreaded program did not have any undefined behavior, especially before
shared is fully implemented.  To truly ensure no undefined behavior, you'd need
the following in the c'tor for core.thread.Thread:

version(safe) {
    assert(0);
}



More information about the Digitalmars-d mailing list