--- Comment #5 from Leandro Lucarella <> 2009-11-01 12:31:57 
PST ---
(In reply to comment #4)
> 1.  I chose to store the bitmask after SENTINEL_POST so that none of the
> assumptions of the sentinel code (such as that the sentinel is immediately
> after the data) changes.

Seems reasonable, the SENTINEL version is not very used anyway.

> 2.  The fact that setBitMask() is a nested function is a minor holdover from
> when the design was a little different.  If anyone really hates it a lot, it
> can be refactored.

I agree is not terrible, but since it's a pretty trivial change I guess it
could be nice to remove it, to improve readability (I don't think is a
performance problem, readability and complexity is my only concern). If you
don't feel like changing it yourself I can upload an amended patch.

> 3.  The mixin is because I needed a lot of the same logic in realloc() and
> extend() and it was complicated enough that I felt it was the lesser of two
> evils to use a mixin, even with the "variables appearing out of nowhere" 
> magic,
> rather than duplicate that logic.

Sure, duplicating code is never a good idea. The question is, why it can't be
done with a plain-old function?

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

Reply via email to