ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 45313: /trunk/ /trunk/doc/: reorderc

From: Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx>
Date: Fri, 5 Oct 2012 19:25:51 +0200
On Fri, Oct 05, 2012 at 06:11:02PM +0200, Joerg Mayer wrote:
> On Thu, Oct 04, 2012 at 06:24:22PM +0000, martinm@xxxxxxxxxxxxx wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45313
> > 
> > User: martinm
> > Date: 2012/10/04 11:24 AM
> > 
> > Log:
> >  This is basically a rewrite from Jakub Zawadzki.
> >  Rather than store the FrameRecord entries in a sorted linked list,
> >  instead use an unsorted GPtrArray, then sort it all at once.
> >  
> >  Also, there is no longer the option to limit the amount of sorting (and memory
> >  used), but a new option means we can avoid writing the output file
> >  altogether if the input file is found already to be in order.
> 
> Sigh - that basically makes it final that reordercap will not be integrated
> into editcap :-(

Why?
Looking at editcap sourcse I don't see any use of linked list?

For duplicate there's array with fixed size (so it'd also benefit from some -l option, which I plan to reintroduce to reordercap),
which could be replaced also with GPtrArray.

And less code -> easier to integrate (was: 404LOC, now: 278LOC)

Cheers,
 Jakub.