Bradley T Hughes wrote:

> len parameters in the sockaddr and sockaddr_un's were all wrong).  Now, 
> the thing *I* would like to know is this: why the hell did this work on 
> other systems?


[my guess]

It shouldn't. Not on systems where the sa_len member exists in struct 
sockaddr (BSD-style).


> -#if defined(BSD44SOCKETS) && !defined(Lynx)
> +#if defined(BSD44SOCKETS) && !defined(Lynx) && !defined(__FreeBSD__)
>      sockname.sun_len = strlen(sockname.sun_path);
>      namelen = SUN_LEN(&sockname);


There's an error in the code above. sun_len isn't supposed to take the 
length of the path, but the length of the whole sockaddr_un structure. 
Thus, it should read:
	sockname.sun_len = strlen(sockname.sun_path) + offsetof(sun_path, 
sockaddr_un);
(or something to that effect)

That extra parameter is usually 2 bytes (uint8 sun_family + uint8 
sun_len). Without those two bytes, the system's kernel would chop off 
two bytes at the end of socket pathname: probably the last char and the 
ending ASCII zero.

That could explain why the last char disappeared. And, in some systems, 
depending on the design of the kernel, the last two could disappear.


> +#elif defined(__FreeBSD__)
> +    namelen = sizeof( sockname ) - sizeof( sockname.sun_path ) +
> +             strlen( sockname.sun_path );
> +    sockname.sun_len = namelen;

This code seems more correct. My guess is it should be used not only in 
FreeBSD, but in all systems that have sun_len. Hell, the first line 
works even on systems without sun_len and is better than the code that 
comes next.

Anybody else saw problems of this kind? OpenBSD, NetBSD, SunOS users, 
maybe? Someone else with sun_len?

-- 
   Thiago Macieira - UFOT Registry number: 1001
  thiagom@mail.com
    ICQ UIN: 1967141  PGP: 0x8F2978D5 and 0xEA9037A5 (PGP 2.x)
      Registered Linux user #65028