1. RE: euTcp4u bug
Here is the fix:
tcp4u.ew:201
while (len=0 and tmp != 0) or i<len do
Chris
Chris Bensler wrote:
> 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. RE: euTcp4u bug
Hi Chris,
Thanks for the info, I'll have a look into it.
I think the tcp4u recv function returns the exact number of bytes
received. I should be able to change peek_sequence to a for loop
to return whatever is in the buffer.
I'll do some more investigation to see if it will effect anything else.
Thanks again,
Ray Smith
http://rays-web.com
Chris Bensler wrote:
> Here is the fix:
>
> tcp4u.ew:201
> while (len=0 and tmp != 0) or i<len do
>
>
> Chris
>
> Chris Bensler wrote:
> > 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
3. RE: euTcp4u bug
Ray, this fix works fine. It's the only thing that is wrong.
assuming the data is {1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9}
before:
peek_sequence(data, 19) would return {1,2,3,4,5,6,7,8,9}
now:
peek_sequence(data,19) will return the whole thing
here is the complete, modified routine:
-- peeks data out of memory and puts it into a sequence
-- now accepts 0 for len
-- specifying 0 for len denotes a null-terminated string, otherwise,
-- peeks 'len' number of bytes.
global function peek_sequence(atom addr, integer len)
integer i, tmp
sequence seq
seq=""
i=0
tmp=peek(addr)
while (len=0 and tmp != 0) or i<len do
seq = append(seq, tmp)
i = i + 1
tmp = peek(addr+i)
end while
return seq
end function
Chris
Ray Smith wrote:
> Hi Chris,
>
> Thanks for the info, I'll have a look into it.
>
> I think the tcp4u recv function returns the exact number of bytes
> received. I should be able to change peek_sequence to a for loop
> to return whatever is in the buffer.
>
> I'll do some more investigation to see if it will effect anything else.
>
> Thanks again,
>
> Ray Smith
> http://rays-web.com
>
>
> Chris Bensler wrote:
> > Here is the fix:
> >
> > tcp4u.ew:201
> > while (len=0 and tmp != 0) or i<len do
> >
> >
> > Chris
> >
> > Chris Bensler wrote:
> > > 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
>
>
4. RE: euTcp4u bug
Hi Chris,
I'm just having a look at the tcp4u_receive() function.
Currently it is calling peek_sequence with the buffer and buffer size.
It would seem reasonable to call peek_sequence with the buffer and the
actual number of bytes received and change peek_sequence to just
perform a "for ... end for" loop with the actual number of bytes
received.
> now:
> peek_sequence(data,19) will return the whole thing
using your version will:
peek_sequence(data,25)
return
{1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9}
or
{1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,0,0,0,0,0}
I think it will return the second which is wrong
I'll look at it tonight and test out my proposed change.
Thanks for finding the bug!
Ray Smith
http://rays-web.com
Chris Bensler wrote:
> Ray, this fix works fine. It's the only thing that is wrong.
>
> assuming the data is {1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9}
>
> before:
> peek_sequence(data, 19) would return {1,2,3,4,5,6,7,8,9}
>
> now:
> peek_sequence(data,19) will return the whole thing
>
>
> here is the complete, modified routine:
>
> -- peeks data out of memory and puts it into a sequence
> -- now accepts 0 for len
> -- specifying 0 for len denotes a null-terminated string, otherwise,
> -- peeks 'len' number of bytes.
> global function peek_sequence(atom addr, integer len)
> integer i, tmp
> sequence seq
>
> seq=""
> i=0
> tmp=peek(addr)
> while (len=0 and tmp != 0) or i<len do
> seq = append(seq, tmp)
> i = i + 1
> tmp = peek(addr+i)
> end while
> return seq
>
> end function
>
>
> Chris
>
>
> Ray Smith wrote:
> > Hi Chris,
> >
> > Thanks for the info, I'll have a look into it.
> >
> > I think the tcp4u recv function returns the exact number of bytes
> > received. I should be able to change peek_sequence to a for loop
> > to return whatever is in the buffer.
> >
> > I'll do some more investigation to see if it will effect anything else.
> >
> > Thanks again,
> >
> > Ray Smith
> > http://rays-web.com
> >
> >
> > Chris Bensler wrote:
> > > Here is the fix:
> > >
> > > tcp4u.ew:201
> > > while (len=0 and tmp != 0) or i<len do
> > >
> > >
> > > Chris
> > >
> > > Chris Bensler wrote:
> > > > 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
> >
> >
5. RE: euTcp4u bug
It doesn't call peek_sequence() using the buffer_size.
It uses the return value from tcp4u_receive(), which is the actual
number of bytes received.
I don't see why tcp4u_receive() would try to peek past the end of the
data.
Chris
Ray Smith wrote:
> Hi Chris,
>
> I'm just having a look at the tcp4u_receive() function.
> Currently it is calling peek_sequence with the buffer and buffer size.
> It would seem reasonable to call peek_sequence with the buffer and the
> actual number of bytes received and change peek_sequence to just
> perform a "for ... end for" loop with the actual number of bytes
> received.
>
> > now:
> > peek_sequence(data,19) will return the whole thing
> using your version will:
>
> peek_sequence(data,25)
>
> return
> {1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9}
> or
> {1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,0,0,0,0,0}
>
> I think it will return the second which is wrong
>
> I'll look at it tonight and test out my proposed change.
>
> Thanks for finding the bug!
>
> Ray Smith
> http://rays-web.com
>
>
> Chris Bensler wrote:
> > Ray, this fix works fine. It's the only thing that is wrong.
> >
> > assuming the data is {1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9}
> >
> > before:
> > peek_sequence(data, 19) would return {1,2,3,4,5,6,7,8,9}
> >
> > now:
> > peek_sequence(data,19) will return the whole thing
> >
> >
> > here is the complete, modified routine:
> >
> > -- peeks data out of memory and puts it into a sequence
> > -- now accepts 0 for len
> > -- specifying 0 for len denotes a null-terminated string, otherwise,
> > -- peeks 'len' number of bytes.
> > global function peek_sequence(atom addr, integer len)
> > integer i, tmp
> > sequence seq
> >
> > seq=""
> > i=0
> > tmp=peek(addr)
> > while (len=0 and tmp != 0) or i<len do
> > seq = append(seq, tmp)
> > i = i + 1
> > tmp = peek(addr+i)
> > end while
> > return seq
> >
> > end function
> >
> >
> > Chris
> >
> >
> > Ray Smith wrote:
> > > Hi Chris,
> > >
> > > Thanks for the info, I'll have a look into it.
> > >
> > > I think the tcp4u recv function returns the exact number of bytes
> > > received. I should be able to change peek_sequence to a for loop
> > > to return whatever is in the buffer.
> > >
> > > I'll do some more investigation to see if it will effect anything else.
> > >
> > > Thanks again,
> > >
> > > Ray Smith
> > > http://rays-web.com
> > >
> > >
> > > Chris Bensler wrote:
> > > > Here is the fix:
> > > >
> > > > tcp4u.ew:201
> > > > while (len=0 and tmp != 0) or i<len do
> > > >
> > > >
> > > > Chris
> > > >
> > > > Chris Bensler wrote:
> > > > > tcp4u_receive() doesn't handle null characters.
> > > > >
<snip>
