Re: setsockopt() compat issue

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Oct 17, 2008 at 08:56:52AM +0100, Iain Hibbert wrote:
> >[...]
> > 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.

Yes. I commited a fix to ffproxy package yesterday.

> 
> 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.

lets just hope there's no binary-only tools that would run into this :)
It affects only 64bit platforms anyway ...

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--