Hi Paul



 RM> Got it, ta. Compiles as is without error under BC4 (doesn't run

 RM> properly, of course). Got 94 "declared but not used" warnings,

 RM> though, good thing they can be turned off .



 PM> Ah, I see what the problem is. I hadn't turned on all warnings. The

 PM> warnings are easy to fix by making all the messages #defines.



Partly done. Btw, why do you like TRUE and FALSE to be ints rather

than #defines?



I took advice from some C magazine once and turned on all possible

warnings in the ide. Most warnings are trivial, but the odd one

picks up a real error. I particularly like "significant digits may

be lost in the conversion" when you try



long x; int y;

y = x;



Me, I'd call that an error. Should require a cast at least.





 PM>  RM> And I *love* the RE: remover....

 PM>

 PM> Caused me lots of grief until I realised that some messages actually

 PM> had *two* RE: prefixes! Aaarrrggghhhh!



Loved the implementation, though - "if I found and killed a RE:

once, go round and look for another one just in case." Three lines

of code. Elegant. Took five seconds to work out why, then smiled.







 RM> and sorting on only the first 25 odd subject chars (the chance of

    



 PM> My original code did pretty much this sort of thing. I changed it to

 PM> read the packets into memory to speed it up.



Makes sense. If you've got the mem to spare, use it. My technique

will necessarily involve reading the source packets twice. I intend

to recommend a Big disk cache .



 PM> If you have a 25 byte subject and the info needed to find the message

 PM> on disk (2 byte index into the packet table + 4 byte offset into the

 PM> file) you end up with 31 bytes per record. This will allow you to sort

 PM> about 2,100 messages.



Agreed. My first version will use more bytes, but should diet

nicely. Will probably suit my needs ok, but if I'm going to give it

away, I'll have to provide the bigpacket option.



 PM> The other approach is to allocate a table of pointers to sortItems.

 PM> Then, each time you need to add another record, allocate memory for

 PM> the sortItem and add it to the table. You'll need to changed the qsort

 PM> compare routine a little as well if you do this.



Hadn't thought of that; ta.



I've rewritten qsort once before for much the same reason.







 PM> You'd probably need to turn on stack checking for it to pick it up. If

 PM> you don't, and you overflow the stack, weird things could happen.

 PM>

 PM> The biggest culprit is the pktCollection class, as it declares a table

 PM> of packets, each a few hundred bytes long.



Found it! (reminds me of an old Naked Vicar joke...)



cheers



 progressing, but slowly - I bin crook this week. The

current bug successfully crashes Turbo Debugger (*not* easy to do),

makes the cursor dash diagonally across the screen, and attempts to

do a printscreen. Sigh.



--- PPoint 1.80