Re: setsockopt() compat issue

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 16 Oct 2008 21:52:37 +0200
    From:        Manuel Bouyer <bouyer%antioche.eu.org@localhost>
    Message-ID:  <20081016195237.GA2935%antioche.eu.org@localhost>

  | Well, maybe we should then. If we're claiming backward compatibility, we
  | should also be bug-compatible, or a software that did run, may not run any
  | more ...

I'd say it depends upon the nature of the bug that was fixed (or is
being exploited in the old cade).

If its the kind of thing where the behaviour was simply undefined (like
for example, assuming that *0 == 0 which some old cade did), then simply
trash it - "undefined" includes "might not work he same way tomorrow",
so if the program was incorrectly using something (setcockopt in this
case I guess) in  a way that just happened to work by accident in older
systems, then tough luck, it works no more.

On the other hand, if the bug was "this is a broken interface, and cannot
possibly work in general, we have to change it" (regardless of how
correct that statement is) and the program in question was simply using
the old interface the way it had been defined to be used (either explicitly
or by common example) and it worked OK (well enough for the prpgram,
perhaps only on the architecture the program was running on), then
the old way should continue to be supported via a compat function.

kre
is running on, then