Re: [Evolution] kernel 2.5 and evolution

[Mika Liljeberg <mika liljeberg welho com>]

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