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.



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

 RM> than #defines?



Defining things as const int rather than #define allows the compiler to do
type checking rather than just blindly substiting the value in. If you use
it for strings, it ensures that there's only one copy, instead of one copy
everytime it's used. Most compilers allow you to merge duplicate string, so
this possibly isn't a great consideration. The down side it that with a
const, the variable always takes up space in the code. With #define it only
uses space it you refer to it. I changed all the messages to #defines and
the exe size dropped 4K!



It's really just something I'm experimenting with. I haven't figured out
whether it's any benefit or not. One disadvantage, as you've seen, is the
extra warnings.



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

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

 RM> picks up a real error.



I usually turn on all warnings, it just that I forgot to do it when I
created the make file. If the compiler flags something as a warning, I
found it's usually best to fix them.



 RM> I particularly like "significant digits may be lost in the

 RM> conversion" when you try



 RM> long x; int y;

 RM> y = x;



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



Calling it an error would probably break too many programs. If I get this
warning, I put a cast on it even though it's not really needed.



 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!



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

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

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



Glad you like it. It took about 5 seconds to implement as well, although it
took several hours to figure out that I needed to do it :-)



BTW, at the moment it only removes the RE: for the purposes of sorting, not
on the final output packet.



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

 RM>     



 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.



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

 RM> will necessarily involve reading the source packets twice. I intend

 RM> to recommend a Big disk cache .



Sounds like you reinventing my original program. I was reading it twice as
well, but it really thrashed the disk.



 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.



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



I'm not sure what joke you're referring to, but if it's filthy and
disgusting lets hear it!



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

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

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

 RM> do a printscreen. Sigh.



Ah yes, that a feature I put in. If you detect an error, print the screen
so you've got something to show technical support :-)





Paul



--- GoldED/2 2.42.G1114