On Tue, 2009-03-03 at 12:10 -0500, Steve Huston wrote: > > > I think this is the wrong solution: If socklen_t isn't a platform > > > portable type then it has no place being used in platform > > > independent header > > Right - the question is, is socklen_t a portable type. I'd argue it > is, and that Windows is about the only popular OS that doesn't define > it natively. Hence, why I added it to IntegerTypes.h.
This is true, but it's only portable in the same way that POSIX is portable ie not (necessarily) to Windows! > > > > - The only platform dependent code should be in > > > subdirectories of > > > qpid/sys, not in qpid/sys itself. So we should change the > > type to be a > > > different type that is platform portable and deal with the > platform > > > specifics in the platform layer instead (simple casting will do). > > > > > > I suggest we just change qpid/sys/Socket.h to use uint32_t > > instead - in > > > fact I will make that change unless anyone complains by the > > end of day. > > 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. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
