<shaver> I need |const CharT *| guidance <scc_only_here_for_a_minute> k <scc_only_here_for_a_minute> let's solve that problem <scc_only_here_for_a_minute> explain to me again exactly what's wrong <scc_only_here_for_a_minute> buffer handles (of all sorts) aren't |const|? <scc_only_here_for_a_minute> but you want them to be? <shaver> nsSharedBufferHandle<PRUnichar> wants to deal in |CharT *| <shaver> well, yeah <shaver> because my underlying strings are very much not for modification by the people with the shared buffer handle. <scc_only_here_for_a_minute> I see <shaver> I could handle BufferHandle being non-const and SharedBufferHandle being const, if that's better (I'm not sure it is) <scc_only_here_for_a_minute> ok <scc_only_here_for_a_minute> here's the solution <scc_only_here_for_a_minute> as with iterators <scc_only_here_for_a_minute> we need two sets of classes <scc_only_here_for_a_minute> one for non-|const| access (as we have now) <scc_only_here_for_a_minute> one for |const| access <scc_only_here_for_a_minute> |const| access classes have constructors from the non-|const| classes <scc_only_here_for_a_minute> if need be <shaver> right. <scc_only_here_for_a_minute> hmmm <scc_only_here_for_a_minute> here's the thing <scc_only_here_for_a_minute> who ever is holding the buffer, really has it in one of the non-|const| ones <shaver> yurk. <shaver> well <scc_only_here_for_a_minute> so if we hand out a |const| one, it's really a reinterpretation of the existing non-|const| one <scc_only_here_for_a_minute> that's OK <shaver> as long as there's no way to get to the non-const buffer through the const one <scc_only_here_for_a_minute> just hairy (conceptually) <shaver> I can handle that <shaver> OK <shaver> should Shared be the const form? <scc_only_here_for_a_minute> hmmm <scc_only_here_for_a_minute> or maybe <scc_only_here_for_a_minute> the handle owns the data <scc_only_here_for_a_minute> and so only it has non-|const| access <scc_only_here_for_a_minute> but that hurts people who are iterating and modifying in place <scc_only_here_for_a_minute> in either case <scc_only_here_for_a_minute> the switch to |const| pointers is going to be a little painful <scc_only_here_for_a_minute> do we have a bug for this? <shaver> we could have nsPrivateSharableString provide GetBufferHandle that returns a SharedBufferHandle, and then have a GetMutableBufferHandle on that handle that could fail in my case (return 0) <shaver> not yet -- I didn't know if it was really a bug =) <scc_only_here_for_a_minute> well, here's the thing <scc_only_here_for_a_minute> the rule for a shared buffer handle is that must not be modified while the reference count is greater than one <scc_only_here_for_a_minute> so the solution to this problem is going to require a little thought to get right <scc_only_here_for_a_minute> we should file a bug <shaver> OK <scc_only_here_for_a_minute> and it should block bug #73009 <shaver> I'd also love a piece of sample code that showed how someone passes a sharable string, and how the lifecycle is properly managed <scc_only_here_for_a_minute> :-) <shaver> because I am so afraid of having some loser |delete| my string while it's being shared <scc_only_here_for_a_minute> they can't <scc_only_here_for_a_minute> the sharing is totally behind the scenes <shaver> OK <scc_only_here_for_a_minute> strings always appear to obey value semantics

re-targeting milestones, starting from a clean slate

giving up ancient string bugs to the new string owner. jag, you'll want to sort through these and see which ones still apply and go with or against the direction in which you intend strings evolve