Re: setsockopt() compat issue

[christos%astron.com@localhost (Christos Zoulas)]

In article <1224230218.576376.902.nullmailer%galant.ukfsn.org@localhost>,
Iain Hibbert  <plunky%rya-online.net@localhost> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>On Thu, 16 Oct 2008, Iain Hibbert wrote:
>
>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.

Most programs will work, buggy ones will not unless we provide compatibility.
I think that in this case we should be compatible, but not bug-compatible
because the cost of maintaining extra code to deal with the very few buggy
programs that will benefit from the compat code does not justify having
writing it or maintaining it. In this case, the program is so buggy that
it has undefined behavior!

christos