On Tue, 2003-01-07 at 11:57, Chris Toshok wrote:
> Attached is a program that runs fine on both freebsd 5.0 rc2 and linux
> 2.4.18-3, and gives the same output. When run like so:
>
> $ sun_test 2 & sun_test 1
>
> you'll see:
>
> sock2's peer = '/tmp/sock1'
> sock1's peer = '/tmp/sock2'
>
Well, I get the same result you do.
> I can't speak to what 2.5.x's output is for this program, but i bet it's
> the same. If it's not it must be a bug in my code :P
According to Joaquim, and I can confirm this, Linux 2.5 returns the
following:
sock1's peer = '/tmp/sock1'
sock2's peer = '/tmp/sock2'
I have to agree that definately looks like a bug in Linux 2.5.
getpeername() seems to return the local address rather than the remote.
> If you comment out the bind(2) call before sock1's connect(2) call then
> sock2's peer shows up as "", but that's because it's not being bound.
Incidentally, orbit does *not* bind the client socket. This means that
getpeername() is *supposed* to return a zero path. Thus, zeroing the
path name is harmless. It's a valid workaround for the Linux 2.5 bug,
and merely redundant with Linux 2.4.
What I *don't* understand is why the orbit code calls getpeername() in
the first place. Maybe they just thought that was the easiest way to get
a valid address structure.
MikaL
_______________________________________________
evolution maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution
