1. euTcp4u bug
tcp4u_receive() doesn't handle null characters.
The string returned is always peeked as a 0-terminated string. I can't
receive a full data stream that contains nulls.
The actual routine itself is written correctly, but the peek_sequence()
routine is flawed. It catches nulls before len is reached.
Chris
2. euTcp4u bug
The function tcp4u_receive() should be changed into:
global function tcp4u_receive(atom socket, integer buff_size, integer time_out)
integer ret
atom buff_addr
sequence buff_seq
buff_addr = allocate(buff_size)
ret = c_func(myTcpRecv, {socket, buff_addr, buff_size, time_out,
TCP4U_FILE_ERROR})
if ret > 0 then
buff_seq = peek_sequence(buff_addr, ret)
ret = TCP4U_SUCCESS -- this line should be added
else
buff_seq = {}
end if
free(buff_addr)
return {ret, buff_seq}
end function
Otherwise, this function, when successful, returns the number of bytes
received instead of the return code in ret.
Regards, Alexander Toresson
Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
3. Re: euTcp4u bug
> Otherwise, this function, when successful, returns the number of bytes
> received instead of the return code in ret.
I'm using euTcp4u in one of my current projects. In my opinion, this
is how it is supposed to act. All error codes are negative values, so
if your call to tcp4u_reveive() failed, then ret would be negative, if
it succeeded, then ret would be positive (number of bytes).
~Greg
4. Re: euTcp4u bug
Greg Haberek wrote:
>
> > Otherwise, this function, when successful, returns the number of bytes
> > received instead of the return code in ret.
>
> I'm using euTcp4u in one of my current projects. In my opinion, this
> is how it is supposed to act. All error codes are negative values, so
> if your call to tcp4u_reveive() failed, then ret would be negative, if
> it succeeded, then ret would be positive (number of bytes).
>
> ~Greg
>
However, the euTcp4u documentation states that it always should return a
return code, not the number of bytes.
Wait, now I see. It states that when it's successful it should return
both "The length in bytes of the received frame" and TCP4U_SUCCESS.
TCP4U_SUCCESS is, however, equal to 1. So that condition should be
removed. It was that which got me confused.
Also, the server.exw and client.exw demos assume that it returns
TCP4U_SUCCESS. These programs send data byte-by-byte, so assuming that
doesn't casue any problem. I based my program on those demos.
original documentation table:
return_code= TCP4U_BUFFERFREED The user's buffer has been released.
TCP4U_CANCELLED The request has been cancelled by TcpAbort or
Tcp4uCleanup.
TCP4U_EMPTYBUFFFER The frame is empty. (Its length is 0 byte).
TCP4U_ERROR An unexpected error has occurred or a blocking
call is already in progress.
TCP4U_INSMEMORY Tcp4w can not allocate its temporary buffers.
TCP4U_OVERFLOW The frame to be received is greater than the
user's buffer.
TCP4U_SOCKETCLOSED The remote host has closed its connection.
TCP4U_SUCCESS The length in bytes of the received frame. The
frame is copied into the user's buffer except the first two bytes.
Regards, Alexander Toresson
Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
