Re: setsockopt() compat issue

[Iain Hibbert <plunky%rya-online.net@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thu, 16 Oct 2008, Iain Hibbert wrote:

> On Thu, 16 Oct 2008, Manuel Bouyer wrote:
>
> > Hello,
> > I'm trying a NetBSD/alpha 4.99.73 on a alpha/3.1 userland. All is going well
> > so far, exept ffproxy which fails wil:
> >   1658 ffproxy  CALL  socket(2,1,6)
> >   1658 ffproxy  RET   socket 0
> >   1658 ffproxy  CALL  setsockopt(0,0xffff,4,0x1ffffd668,8)
>
> setsockopt(0, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(64-bit))
>
> >   1658 ffproxy  RET   setsockopt -1 errno 22 Invalid argument
> >   1658 ffproxy  CALL  close(0)
> >   1658 ffproxy  RET   close 0
> >
> > Any idea if it can be fixed ?
>
> well, everything can be fixed of course :)
>
> I think this may be because of sockopt changes which leaves it at my door.
>
> What is the size of int on alpha?  I'm guessing from the other comments
> that it might be 32-bit but the above syscall seems to be passing a 64-bit
> value, which is somewhat problematic (why would ffproxy do that?)

I looked at this, it seems ffproxy does:

        void *foo

        s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

        setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &foo, sizeof(foo));

with actually no initialisation of foo at all, it just hopes that its a
nonzero value which is a bit of a WTF in itself.

The reason it failed is that on Alpha, a pointer is 64-bit and an int is
32-bit.

> There has been a change in behaviour. The original code only failed if the
> value given was smaller than an int, whereas now it fails if it is not the
> same size as an int.
>
> sockopt_get() could be changed to fail only if the given value is smaller
> than the requested value but should it?  IIRC there were a couple of
> places where not even this was checked (because it had minimum of MLEN to
> look at, there was no worries about reading invalid addresses)
>
> personally, I think that inducing bad code to fail is always a good idea,
> but compatibility is good and I'm welcome to suggestions about how to
> proceed..

further to this, my opinion is that compatibility with features is
essential, but with bugs maybe not so necessary. I'm still open to how to
proceed.

iain
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iQEcBAEBAgAGBQJI+EVEAAoJEPFJxoMWDXVDQ2YIAI4K5GVluFHfUBIsX3T4t1hw
1bRZTx+zfDpzGiBvyEAbKHXnZFFDaHr3Q1A8TkHARasxwpWP3LK3fGSZ9H5/U20q
WBSuy3z/pBrdY+MdJO7Ct9jRUS9qEAlaFS51yB0YJkqAjXET11BgBV6xB9fRAgEU
JGERk9dIHmfB9rE5LL+ImXPnC7AF6/WqJ/4PDmZ6JCAT35wjq2+CykDhQ7E5fheY
85Z+8RmQh8cR8HMXedYLxlIF8yLv42rVJnuVfk4DG+WKyLrRX4cO5Gt86jktyf32
PqyNMH52BHT4LU7U8OBhWynC8D0YlNuMWLPD3wCN3QWKAvAeL2gpGsyvFlahaZU=
=Ixkq
-----END PGP SIGNATURE-----