> > 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. > > - 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? -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
