PM>> Sounds like you've got a stray pointer corrupting memory. You're

 PM>> probably getting away with it under some circumstances but not

 PM>> others.



 RM> Quite likely.



 PM>> I would have thought TD386 would be able to trap that

 PM>> problem though.



 RM> But TD386 won't run in the setup that the program fails under.



I was thinking that TD386 would pick up an invalid memory reference even
though it wouldn't necessarily cause the program to fail. Possibly it
doesn't though. You'd need something like Memcheck to pick it up I guess.
Or OS/2 of course :-)



 RM> (I've renamed it RS.EXE, btw, for Roy's Sort. It's faster to type

 RM> on the command line, and I get a get a perverse pleasure from

 RM> swearing at it when it contradicts me.)



ROFL! Watch out, it'll start contradicting itself soon. Probably start
generating its own messages as well.



 PM>> If you want, send your code back to me and I'll

 PM>> compile and run it under OS/2 and see if it can pick up any memory

 PM>> addressing problems.



 RM> It may come to that. Needs a bit of cosmetic surgery first, though.



It's ok, I've got a strong heart. It's not likely to fail when I see what
you done to my code.



 PM>> Are you running with stack checking turned on?



 RM> That option doesn't seem to exist in BC++3.0, but I've definitely

 RM> got it turned on in BC++4, and it hasn't tripped yet.



I don't have my 3.0 manual handy, but in 3.1 the option is -N. If you're
using the new version of the classes I sent you, you probably won't have
much trouble with the stack.



 RM> I've worked out the _stklen variable, btw, it just hadn't occurred to

 RM> me that it could be assigned at runtime, I'd thought it was a compile

 RM> time thing.



When I was looking for it, I assumed it would be a linker option. When I
couldn't find it I looked for a compiler option. Then, out of desperation,
I looked for a run time parameter and there it was!





Paul



--- GoldED/2 2.42.G1114