qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: About socklen_t
Date Fri, 27 Feb 2009 14:06:10 GMT
Manuel Teira Paz wrote:
> Alan Conway escribió:
>> Manuel Teira Paz wrote:
>>> Hello again.
>>> During the compilation stage of the trunk, I run into this error:
>>> source='qpid/broker/Bridge.cpp' object='qpid/broker/Bridge.lo' 
>>> libtool=yes \
>>> DEPDIR=.deps depmode=dashXmstdout /bin/bash ../build-aux/depcomp \
>>> /bin/bash ../libtool --tag=CXX    --mode=compile CC -g -m64 
>>> -DHAVE_CONFIG_H -I. -Igen -I./gen     -I/opt/qpid/include 
>>> -library=stlport4 -mt -c -o qpid/broker/Bridge.lo qpid/broker/Bridge.cpp
>>> CC -g -m64 -DHAVE_CONFIG_H -I. -Igen -I./gen -I/opt/qpid/include 
>>> -library=stlport4 -mt -c qpid/broker/Bridge.cpp  -KPIC -DPIC -o 
>>> qpid/broker/.libs/Bridge.o
>>> "./qpid/sys/Socket.h", line 96: Error: socklen_t is not defined.
>>> "qpid/broker/Bridge.cpp", line 170: Warning: id hides 
>>> qpid::broker::Bridge::id.
>>> 1 Error(s) and 1 Warning(s) detected.
>>> I started looking in my Solaris system, where socklen_t is defined, 
>>> and the place was sys/socket.h. Nevertheless, I see that the way 
>>> integer types are intended to be imported now regardless the platform 
>>> is:
>>> qpid/sys/IntegerTypes.h
>>> that relies on a platform dependent file.
>>> The question here is, where exactly the socklen_t is suposed to be 
>>> defined in linux or a posix compliant system? The posix 
>>> IntegerTypes.h in qpid is just including <stdint.h>, but after a fast 
>>> look in an Ubuntu system, I didn't find there any declaration for 
>>> socklen_t. Another curious thing about socklen_t is what I've found 
>>> here:
>>> http://portabilityblog.com/blog/archives/7-socklen_t-confusion.html
>>> Also, the declaration for solaris is not trivial:
>>> #if defined(_XPG4_2) && !defined(_XPG5) && !defined(_LP64)
>>> typedef size_t          socklen_t;
>>> #else
>>> typedef uint32_t        socklen_t;
>>> #endif  /* defined(_XPG4_2) && !defined(_XPG5) && !defined(_LP64)
>>> Anyway, it seems to rely to uint32_t on normal cases.
>>> What do you think is the best way to proceed here? Just add a 
>>> #include <sys/socket.h> in the posix IntegerTypes.h?     
>> I would only #include socket.h in network-related files that need 
>> socklen_t, it's not really a generic integer type it's specific to 
>> sockets. Where is it being used that we're not already including 
>> socket.h?
> In qpid/sys/Socket.h.
> Furthermore, socklen_t is defined for the windows platform in their 
> specific IntegerTypes.h, that was what led me to think that perhaps 
> including socket.h in the posix counterpart, could be a (somewhat) 
> coherent move.
> Another posibility would be to include sys/socket.h in 
> qpid/sys/Socket.h. But since this is not posix specific, perhaps the 
> windows port could get damaged.

That would be my preference, check with Steve if it's OK on windows. I'm fairly 
sure it is. If not you could add a sys/socklen.h with an #ifdef to include the 
appropriate file and include that in Socket.h.

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

View raw message