On Fri, Mar 26, 2010 at 10:32 PM, nathan binkert <[email protected]> wrote: >> #1 sounds pretty good to me... 2 & 3 seem like overkill. I don't >> think the overhead of the null pointer is that bad. > Ok, cool. I'll cook up a diff. > >>> I'm partial to doing 1, 3, or nothing (in that order.) With #1, we >>> could also add a feature that requires the senderState to be popped at >>> every level and where we assert in the Packet destructor that >>> senderState is NULL. This would ensure that you're not attaching >>> things to sender state and forgetting about them (causing either a >>> memory leak, or a programming error because you forgot to do >>> something.) > > What about this feature where we ensure that senderState is NULL when > we call the destructor. Think that's worth trying? I could give that > a shot and see what happens. Any reason not to do this? (The > alternative is to try to delete the chain of sender state objects.) > Seems that one way or another we should try to avoid the memory leak.
That seems reasonable to me. You could always just put a warn() in if it's non-null and see if you hit it. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
