Hello, We do reset ReadCount while sending the objects to pool because otherwise sometimes garbage is served. I know that this is a workaround not a fix.
Best Regards, SZ ----- Original Message ----- From: "Arno Garrels" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Friday, February 23, 2007 9:49 PM Subject: Re: [twsocket] FReadCount and overflows > Markus, > > In latest versions, if you use D6 or better STREAM64 is defined > by default. Unless you transfered data volumes beyond 2^63-1 bytes > there won't be a problem ;-) Property ReadCount is reset to zero > before each transfer, so that has nothing to do with 7x24 apps. > > --- > Arno Garrels [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > > > > Markus Humm wrote: >> Hello, >> >> while searching a serious problem in one of my apps I decided to run >> the affected part from the IDE. It contains two TCP Servers built with >> TWSocket (ICS V5.20, D2006). >> >> As I checked it this morning the debugger told me there is some >> integer overflow and when I looked at the line causing it it was line >> 3728 in WSocket.pas where FReadCount gets incremented with the number >> of bytes read. >> >> Above that very line is some statement that the thing might overflow >> and that either overflow-checking should be used or Int64 instead of >> longint. (better both as int64 can overflow as well and I'm doing 7x24 >> stuff) >> >> I've checked where it was used and then decided to comment the line >> out and rerun my app. But it stll makes me wonder: >> >> - why hasn't there anything beend done if the developpers are aware >> that there is a problem? >> - Did nobody so far encounter this? No one writing 7x24 apps with ICS? >> - Are there any other bombs of that type? >> - Any fix for this planned or even in the current version? (how does >> the current V5, yes I can't switch right now! differ from 5.20?) >> >> The app. also uses a DLL which has a TWSocket. The DLL has its own >> thread for the TWSocket because it is loaded dynamically and should >> handle its messages on its own. Will this a problem there? because I >> haven't recompiled it yet. What will happen? Will this depend on >> whether it was compiled with R+ or not? >> >> The other side of these two TCP connections is a simple test program >> which hasn't been recompiled either. Will it crash when it encounters >> this bug? Or will it simply overflow? I assume it depends on $R+/- >> here as well? >> >> Greetings >> >> Markus > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be