messagebus AF_UNIX listening socket

[Jakub Piotr Cłapa]

Jakub Piotr Cłapa wrote:
> Havoc Pennington wrote:
> 
>> On Tue, 2005-08-02 at 21:07 +0200, Jakub Piotr Cłapa wrote:
>>
>>> Is the messagebus listening on UNIX socket '\x00/tmp/dbus-Iv42EWtOTH' 
>>> + '\x00' * 87 (yes! 87 NULL bytes) on purpose?
>>>
>>> I think that anybody seeing
>>> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Iv42EWtOTH,guid=7a3ced42fbeeaf14bbafceecee692d00 
>>>
>>> would expect that the socket is named "/tmp/dbus-Iv42EWtOTH" and pass 
>>> "\x00/tmp/dbus-Iv42EWtOTH" to connect()
>>
>> I'm not sure whether this is how abstract sockets have to work or not;
>> apparently I thought it was when writing that code.
>>
>> [...]
> 
> I was surprised too and it took quite a while to find where the problem 
> lies. (strace proved to be invaluable)
> 
>> I guess bind()/connect() might allow a shorter addrlen, but it's a
>> little tricky to compute since addrlen is the length of the whole struct
>> and not just the sun_path bit so we'd have to do
>> _DBUS_STRUCT_OFFSET(sun_path) + path len or something.
> 
> Probably yes --- we'll need to compute the accurate length of the struct 
> counting only meaningful characters. Or document that the address is 
> padded but it can be a portability problem and would probably look quite 
> odd. ;]

And what now?
If we change the current implementation we would break the backwards 
compatibility (maybe we could try this at some point in the future with 
some other conflicting changes) so for now maybe just document that the 
address is padded with zeros? It really causes much confusion when you 
try to connect to the message bus w/o using the reference 
implementation. (and the spec clearly states that it should be easy to 
write alternative implementations using only the specification ;)

-- 
Regards,
Jakub Piotr Cłapa