Also it's handy to be able to instrument free without a lot of faffing around (I used to have code to instrument it). Still, none of the advantages are particularly compelling so I'm leaning towards making this change, let me think about it...
On Sun, Jun 03, 2012 at 09:13:53PM +0100, Nicholas Marriott wrote: > It forces you to think about the lifetime of what you are freeing rather > than just doing it. Remembering to add them in is not a problem, because > it is a fatal error if you forget... that's an easy bug to spot :-). > > > > On Sun, Jun 03, 2012 at 08:23:46PM +0100, Thomas Adam wrote: > > Hi, > > > > On 3 June 2012 20:19, Nicholas Marriott <nicholas.marri...@gmail.com> wrote: > > > There are 300-odd calls to xfree in tmux and it looks like only about 50 > > > have a check. Those are the ones where we explicitly know that NULL is a > > > possibility. I don't think it adds much work to do this, I just don't > > > know if it actually helps to catch bugs or document anything. > > > > Hmm. I'm still not sure what bugs you might be referring to here, > > when it's a no-op when calling free() in that way? You could even > > look at it the other way around and say the other (300-50) calls to > > xfree() which don't have this check actually needs them, and indeed, > > should the implementation of the surrounding code ever change, they'd > > have to _remember_ to add them in, presumably, if it's to be > > compliant. > > > > Kindly, > > > > -- Thomas Adam ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
