qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject RE: RFC (Was About socklen_t )
Date Wed, 04 Mar 2009 03:40:46 GMT
On Tue, 2009-03-03 at 13:06 -0500, Andrew Stitcher wrote:
> On Tue, 2009-03-03 at 12:10 -0500, Steve Huston wrote:
> > I also think this is good, for a different reason... Taking Manuel's
> > case that sometimes socklen_t is 32 bits, sometimes 64, it may help
> to
> > avoid wierd run-time errors when a 32-bit app links to a qpid lib
> > built with 64-bit socklen_t. That couldn't happen with socklen_t's
> > current usage buried away from the public API as it is, but could it
> > be an issue if the type appeared closer to the user?
> As I indicated in my original mail I have a hard time believing that
> even 32 bits is necessary for a socket address length so I can't
> imagine
> that casting from a uint32_t to one of size_t/socklen_t/uint64 etc.
> could actually be a real problem.

I've now looked at the cause of this whole issue and realised that we're
discussing a type that isn't actually really used in our code!

The problem is in the definition of Socket::accept() -

But our code only ever calls socket::accept(0,0)! It never actually
cares about the connecting address as a result of the accept.

Even if we wanted to return the connecting address from accept the way
we should do that which is consonant with the rest of the Socket class
is as a string address/port (I think this is yucky myself). In any event
we know we can can only get a TCP/TCP6 address out of here cause we
accepted on a TCP/TCP6 socket.

But given that we don't currently use the returned address I'm just
going to remove it from the API.

To leave the signature Socket* Socket::accept(void);

That should remove both sockaddr and socklen_t from the Socket API.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message