Fastream Technologies wrote:
> 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. 

Sure, otherwise you add bytes transfered in previous sessions to
the next client. What do you think is a fix? Even if there was
an Int256 it may overflow as well if you keep connections alive

Arno Garrels [TeamICS]

> Best Regards,
> SZ
> ----- Original Message -----
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing" <>
> 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]
>> 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
>> Visit our website at
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to