Hello Max,
I was able to reproduce the AV!
Please try this change:
function TCustomSocksWSocket.DoRecv()
[..]
{$IFDEF WIN32}
//Move(FRcvBuf[FSocksRcvdPtr], Buffer, FSocksRcvdCnt); // ==>
Move(FRcvBuf[FSocksRcvdPtr], Buffer^, FSocksRcvdCnt); // <==
{$ENDIF}
Hi Arno,
Yes, it's helps ! But I will perform some heavy tests for sure...
Thanx for the fix !!!
---
With best regards, Max Terentiev.
Business Software Products.
AMS Development Team.
supp...@bspdev.com
- Original Message -
From: "Arno Garrels"
To: "ICS support mailing"
Sent: Sun
It is rather strange Delphi compiler does not give error on this! C compiler
would I think.
On Sun, Nov 1, 2009 at 12:29 PM, Max Terentiev wrote:
> Hi Arno,
>
> Yes, it's helps ! But I will perform some heavy tests for sure...
>
> Thanx for the fix !!!
>
>
> ---
> With best regards, Max Terentie
Fastream Technologies wrote:
> It is rather strange Delphi compiler does not give error on this! C
> compiler would I think.
It effects SOCKS connections only. It isn't a compiler specific bug
but timing related. The buggy code wasn't called at all until I set a
break point in TCustomSocksWSocket.
I think a C compiler would complain if you pass a char instead of char* in
compile time. That's what I meant.
On Sun, Nov 1, 2009 at 8:07 PM, Arno Garrels wrote:
> Fastream Technologies wrote:
> > It is rather strange Delphi compiler does not give error on this! C
> > compiler would I think.
>
>
Fastream Technologies wrote:
> I think a C compiler would complain if you pass a char instead of
> char* in compile time. That's what I meant.
Look at the declaration of Move() that makes it clear.
--
Arno Garrels
>
> On Sun, Nov 1, 2009 at 8:07 PM, Arno Garrels
> wrote:
>
>> Fastream Techn
Hi Arno,
I think all Move() calls in ICS code should be checked...
Bugs maybe not only in this place
---
With best regards, Max Terentiev.
Business Software Products.
AMS Development Team.
supp...@bspdev.com
- Original Message -
From: "Arno Garrels"
To: "ICS support mailing"
Se
