qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira Paz <mte...@tid.es>
Subject RFC (Was About socklen_t )
Date Tue, 03 Mar 2009 16:10:29 GMT
Coming back to this issue.

I don't like the option of having a different Socket.h for windows and 
posix, since they would only differ in one include sentence.

On the other hand, I don't see any problem into having socklen_t defined 
into IntegerTypes.h, since that's what it is: an integer type. Perhaps 
including the whole <sys/socket.h> in the posix IntegerTypes.h is not 
very polite, but, what other options do we have?

To have a specific SocketTypes.h ? It seems a little odd, just to 
support socklen_t. Or to define a own typedef to be used in the 
Socket::accept method (the only one using socklen_t actually)?

So, my +1 for adding sys/socket.h to the posix IntegerTypes.h header.




Manuel Teira Paz escribió:
> Steve Huston escribió:
>   
>>> -----Original Message-----
>>> From: Alan Conway [mailto:aconway@redhat.com] 
>>>
>>> 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.
>>>     
>>>       
>> Adding a #include <sys/socket.h> would require a platform-specific
>> ifdef, which I thought were highly frowned on. The approach taken in
>> similar situations is to add a platform-specific header file
>> (qpid/sys/posix/sys_socket.h or similar) and include that from
>> qpid/sys/Socket.h.
>>   
>>     
> That's true. I was just hoping that perhaps a sys/socket.h also existed 
> on windows. Unfortunately, that's not the case.
>
> But, if I'm not missunderstanding you: your proposal is to move the 
> Socket definitions to a Socket.h specific file for Posix and Windows, 
> and doing the decission of what to include in the upper level Socket.h 
> file? isn't that leading to a lot of duplicated code? Actually, the 
> windows and posix specific Socket definitions are only going to differ 
> in one line. I know that this is the usual way to proceed, but is it 
> used in extreme cases like this, where both models just differ in the 
> inclusion of a header?
>
> Or did I miss something?
>
> Regards.
>
> --
> Manuel
>   
>> I put the socklen_t typedef for Windows in IntegerTypes.h because
>> Windows doesn't define socklen_t anywhere.
>>
>> -Steve
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>   
>>     
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>   


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


Mime
View raw message