OpenEuphoria

RE: IRC client

• Posted by bensler at mail.com Jan 14, 2002
• 400 views

Still looking at that code..
   port_addr = allocate(2)
   poke(port_addr, port)

Wouldn't this poke only the 1st byte of the port value?

Chris


Kat wrote:
> On 15 Jan 2002, at 4:38, bensler at mail.com wrote:
> 
> > 
> > Now that I relook at Kat's fix, I'm surprised to find that she was 
> > incorrect! Shame on you Kat :P
> > 
> > Socket variables should be atoms, but the second fix allocates 4 bytes 
> > for the port, when it can never exceed 2 bytes.
> 
> Naturally, i would not have figured out the 2nd patch if i had not still 
> had a 
> problem. Once i did this, everything ran fine. <shrug>
> 
> > So, yes, only the socket variables need to be changed to atoms.
> > Other than that, I've used every TCP routine in the lib, and have run 
> > into no problems.
> > 
> > 
> > Chris
> > 
> > 
> > Ray Smith wrote:
> > > 
> > > bensler at mail.com wrote:
> > > 
> > > Hi Chris (and Kat),
> > > 
> > > I have taken your advice and attempted to update euTcp4u.
> > > 
> > > I put the below changes into my source and tried to run my test
> > > programs but they failed.
> > > 
> > > With the changes you have made can you run the "server.exw" and
> > > "client.exw" that come with euTcp4u?
> > > 
> > > I left "connect_socket" as an atom but removed the second change and
> > > my test programs work again.
> > > Does your IRC code work if the second change is not used?
> 
> No, it didn't. I still had a problem, which this patch took care of. 
> However, i 
> dio not remember if it was a problem in tcp4u, or the 2-byte allocation 
> code. 
> For normal web browsing on port 80, 2 bytes worked fine, i ran into 
> problem 
> when using ports over 32767 for localhost connections, like 50004. Maybe 
> 
> it's a problem with the sign bit on a signed 2byte signed integer? I 
> don't just 
> remember, sorry, but the 4-byte allocation made it work like a breeze.
> 
> I still have not gotten my irc code working again. The actual connect 
> part is 
> fine, as far as i can tell, but the server-specific logging into nested 
> sequences is the problem,, i wish we could get nested values in huge 
> sequences in debug, displayed as needed. The code to store data is like 
> 8 
> lines, the code to display fields as i debug is 50+ lines. Doing an 
> abort to get 
> a ex.err still doesn't show me enough. 
> 
> Kat
> 
>