View mode: basic / threaded / horizontal-split · Log in · Help
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> dsimcha wrote:
> > Ok, I understand the basic principle of a reap, but if it's going to convert to a
> > heap when you try to delete something, why not just improve the standard GC heap,
> > i.e. by making per-thread heaps?
> The problem with per-thread heaps is immutable data can be passed
> between threads.

What does this have to do with anything?  If allocation is done w/o locking by
using TLS, (manual) freeing could simply check that the thread ID of the block
matches the thread ID of the thread doing the freeing and if so, free the memory
to the thread-local heap w/o locking.  Of course, GCing would still have to stop
the world.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Adam D. Ruppe wrote:
> With safe by default, you'd probably make existing code compile just by
> slapping @trusted: at the top and being done with it. That's not actually
> safe - you're just telling the compiler to shut up about it.

That's right, and it's exactly what happened when Java required 
exception specifications for all thrown exceptions. It's viral, and 
people would just write wrappers to catch/ignore all exceptions, 
intending to "fix it" later.

But the fixing later never came, and the app would silently ignore all 
errors.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright Wrote:

> Andrei Alexandrescu wrote:
> > Nick Sabalausky wrote:
> >> Sounds great! The lower-grained safeness makes a lot of sense, and I'm 
> >> thrilled at the idea of safe D finally encompassing more than just 
> >> memory safety - I'd been hoping to see that happen ever since I first 
> >> heard that "safeD" only ment memory-safe. 
> > 
> > I can think of division by zero as an example. What others are out there?
> 
> Casting away const/immutable/shared.

I posted in the other thread how casting to immutable/shared can be just as bad. A leaked reference prior to casting to immutable/shared is in effect the same as casting away shared. No matter how you mix thread local and shared, or mutable and immutable, you still have the same undefined behavior
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
On 2009-11-05 16:40:11 -0500, "Adam D. Ruppe" <destructionator@gmail.com> said:

> Which is going to work best for existing code? With Walter's idea, you
> compile it, then fix functions piece by piece to make them safe. Since your
> other unsafe functions can still call them, the change is localized and you
> get safer with each revision.
> 
> With safe by default, you'd probably make existing code compile just by
> slapping @trusted: at the top and being done with it. That's not actually
> safe - you're just telling the compiler to shut up about it.

That's a great point. Thank you Adam. I changed my mind, let's keep 
unsafe as the default.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Nick Sabalausky wrote:
>>> Sounds great! The lower-grained safeness makes a lot of sense, and 
>>> I'm thrilled at the idea of safe D finally encompassing more than 
>>> just memory safety - I'd been hoping to see that happen ever since I 
>>> first heard that "safeD" only ment memory-safe. 
>>
>> I can think of division by zero as an example. What others are out there?
> 
> Casting away const/immutable/shared.

I think those lead to memory errors :o).

Andrei
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> Well I'm thinking that often when you use a region, the memory
>> consumption is not really large. If it's really large, then you may be
>> better off just using the GC because it means you do a lot of stuff. But
>> I'm sure I'm ignoring a few important applications.
>> Andrei
> 
> By not really large, how big are we talking?  Less than a few 10s of KB?  If so, I
> think just having the whole thing scanned would be feasible.

Honest, I don't know. Only real-life usage might tell. At any rate, a 
few 10s of KBs would definitely work for many of my own applications.

Andrei
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Jason House wrote:
> I posted in the other thread how casting to immutable/shared can be
> just as bad. A leaked reference prior to casting to immutable/shared
> is in effect the same as casting away shared. No matter how you mix
> thread local and shared, or mutable and immutable, you still have the
> same undefined behavior

Not undefined, it's just that the compiler can't prove it's defined 
behavior. Hence, such code would go into a trusted function.
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
On 2009-11-05 17:11:38 -0500, Walter Bright <newshound1@digitalmars.com> said:

> dsimcha wrote:
>> Ok, I understand the basic principle of a reap, but if it's going to 
>> convert to a
>> heap when you try to delete something, why not just improve the 
>> standard GC heap,
>> i.e. by making per-thread heaps?
> 
> The problem with per-thread heaps is immutable data can be passed 
> between threads.

Well, if that's a problem you could fix it by making immutable not 
shared unless you also put the shared attribute:

	immutable Object o;        // thread-local
	shared immutable Object o; // visible from all threads

I think having per-thread heaps is a worthy goal.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
On Thu, 05 Nov 2009 17:49:33 -0500, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Jason House wrote:
>> I posted in the other thread how casting to immutable/shared can be
>> just as bad. A leaked reference prior to casting to immutable/shared
>> is in effect the same as casting away shared. No matter how you mix
>> thread local and shared, or mutable and immutable, you still have the
>> same undefined behavior
>
> Not undefined, it's just that the compiler can't prove it's defined  
> behavior. Hence, such code would go into a trusted function.

But how does such a trusted function guarantee that the invariant/shared  
reference has no other aliases?  The point is, there is no way to write  
such a function in good faith because you can't guarantee it's actually  
safe, it's still up to the user of the function.  My understanding is that  
a @trusted function should be provably safe even if the compiler can't  
prove it.

-Steve
November 05, 2009
Re: Safety, undefined behavior, @safe, @trusted
Walter Bright wrote:
> Jason House wrote:
>> I posted in the other thread how casting to immutable/shared can be
>> just as bad. A leaked reference prior to casting to immutable/shared
>> is in effect the same as casting away shared. No matter how you mix
>> thread local and shared, or mutable and immutable, you still have the
>> same undefined behavior
> 
> Not undefined, it's just that the compiler can't prove it's defined 
> behavior. Hence, such code would go into a trusted function.

Are we in agreement that @safe functions have bounds checking on 
regardless of -release?

Andrei
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home