--- Comment #62 from 2010-07-28 12:49:49 PDT ---
(In reply to comment #61)
> Even when I agree that the GC needs a lot of refactoring, I don't think it's a
> good idea to include it in this patch, it makes much harder to understand it
> and it might introduce some subtle bugs that will be very hard to track down 
> in
> so many changes.

I have to agree, but I did these changes in order to make storing a bitmask
configurable, and to properly support SENTINEL. The changes the original patch
did weren't very small either.

I see 4 options:
1. keep this anyway
2. keep the old gcx.d around and apply the changes to a new incarnation of
gcx.d, and let the user choose the GC implementation at startup or compile time
3. only accept the compiler patch, and wait for Leandro's new GC
4. revert to the previous version of my patch (of course I wouldn't like this
at all)

Which is it?

I also wonder about D2. The array appending issue makes porting the Tango patch

> > Also, shouldn't functions like freeNoSync check for interior pointers? What
> > happens if you call it with such a pointer?
> I don't think so, it should be undefined behavior (based on C's free()).

Then the code should probably check whether the pointer is valid, and abort()
or throw an exception if not. I don't think intentionally introducing random
behavior when you could avoid it is a good idea. Also the documentation
comments in Memory.d seem to disagree with your assessment.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to