ref is unsafe

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Jan 2 15:06:24 PST 2013


On Wed, Jan 02, 2013 at 05:52:54PM -0500, Jonathan M Davis wrote:
> On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> > Again, I argue that D is a system language and there are many
> > possibilities to break @safity. Although fixing holes does make
> > sense in general, it does not make sense fixing obvious issues so
> > that plenty of code becomes uncompilable and @safity usage becomes
> > very annoying.
> 
> Then we're going to have to disagree, and I believe that Walter and
> Andrei are completely with me on this one. If all of the constructs
> that you use are @safe, then it should be _guaranteed_ that your
> program is memory-safe. That's what @safe is for. Yes, it can be
> gotten around if the programmer marks @system code as @trusted when
> it's not really memory-safe, but that's the programmer's problem.
> @safe is not doing it's job and is completely pointless if it has any
> holes in it beyond programmers mislabeling functions as @trusted.
[...]

All extern(C) functions must be @system by default. It makes no sense to
allow a @safe extern(C) function, since there is no way for the compiler
to verify anything at all. The best you can do is @trusted.


T

-- 
Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"


More information about the Digitalmars-d mailing list